----- Original Message ----- > From: "Anthony Liguori" <anthony@xxxxxxxxxxxxx> > To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, libvir-list@xxxxxxxxxx, qemu-devel@xxxxxxxxxx, "Gleb Natapov" > <gleb@xxxxxxxxxx>, "Jiri Denemark" <jdenemar@xxxxxxxxxx>, "Avi Kivity" <avi@xxxxxxxxxx>, arch@xxxxxxxxx > Sent: Saturday, March 10, 2012 1:24:47 PM > Subject: Re: [Qemu-devel] Modern CPU models cannot be used with libvirt > > On 03/10/2012 09:58 AM, Eduardo Habkost wrote: > > On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote: > >>> > >>> I could have sworn we had this discussion a year ago or so, and > >>> had decided > >>> that the default CPU models would be in something like > >>> /usr/share/qemu/cpu-x86_64.conf > >>> and loaded regardless of the -nodefconfig setting. > >>> /etc/qemu/target-x86_64.conf > >>> would be solely for end user configuration changes, not for QEMU > >>> builtin > >>> defaults. > >>> > >>> But looking at the code in QEMU, it doesn't seem we ever > >>> implemented this ? > >> > >> Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu > >> RPMs but, > >> contrary to our normal RHEL development practice, it was not based > >> on > >> a cherry-pick of an upstream patch :-( > >> > >> For sake of reference, I'm attaching the two patches from the > >> RHEL6 source > >> RPM that do what I'm describing > >> > >> NB, I'm not neccessarily advocating these patches for upstream. I > >> still > >> maintain that libvirt should write out a config file containing > >> the > >> exact CPU model description it desires and specify that with > >> -readconfig. > >> The end result would be identical from QEMU's POV and it would > >> avoid > >> playing games with QEMU's config loading code. > > > > I agree that libvirt should just write the config somewhere. The > > problem > > here is to define: 1) what information should be mandatory on that > > config data; 2) who should be responsible to test and maintain sane > > defaults (and where should they be maintained). > > > > The current cpudef definitions are simply too low-level to require > > it to > > be written from scratch. Lots of testing have to be done to make > > sure we > > have working combinations of CPUID bits defined, so they can be > > used as > > defaults or templates. Not facilitating reuse of those tested > > defauls/templates by libvirt is duplication of efforts. > > > > Really, if we expect libvirt to define all the CPU bits from > > scratch on > > a config file, we could as well just expect libvirt to open > > /dev/kvm > > itself and call the all CPUID setup ioctl()s itself. That's how > > low-level some of the cpudef bits are. > > Let's step back here. > > Why are you writing these patches? It's probably not because you > have a desire > to say -cpu Westmere when you run QEMU on your laptop. I'd wager to > say that no > human has ever done that or that if they had, they did so by accident > because > they read documentation and thought they had to. > > Humans probably do one of two things: 1) no cpu option or 2) -cpu > host. > > So then why are you introducing -cpu Westmere? Because ovirt-engine > has a > concept of datacenters and the entire datacenter has to use a > compatible CPU > model to allow migration compatibility. Today, the interface that > ovirt-engine > exposes is based on CPU codenames. Presumably ovirt-engine wants to > add a > Westmere CPU group and as such have levied a requirement down the > stack to QEMU. > > But there's no intrinsic reason why it uses CPU model names. VMware > doesn't do > this. It has a concept of compatibility groups[1]. s/has/had That was back in the 3.5 days and it was hit and miss, it relied on a user putting the same kind of machines in the resource groups and often caused issues. Now they've moved up to a model very similar to what we're using: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212 > > oVirt could just as well define compatibility groups like GroupA, > GroupB, > GroupC, etc. and then the -cpu option we would be discussing would be > -cpu GroupA. > > This is why it's a configuration option and not builtin to QEMU. > It's a user > interface as as such, should be defined at a higher level. > > Perhaps it really should be VDSM that is providing the model info to > libvirt? > Then they can add whatever groups then want whenever they want as > long as we > have the appropriate feature bits. I think the "real" (model specific) names are the best place to start. But if a user wants to override those with their own specific types then it should be allowed > > P.S. I spent 30 minutes the other day helping a user who was > attempting to > figure out whether his processor was a Conroe, Penryn, etc. Making > this > determination is fairly difficult and it makes me wonder whether > having CPU code > names is even the best interface for oVirt.. I think that was more about a bad choice in UI than a bad choice in the architecture. It should be made clear to a user what kind of machine they have and what it's capabilities are This bug was borne out of that issue https://bugzilla.redhat.com/show_bug.cgi?id=799708 > > [1] > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 > > Regards, > > Anthony Liguori > > > > > (Also, there are additional low-level bits that really have to be > > maintained somewhere, just to have sane defaults. Currently many > > CPUID > > leafs are exposed to the guest without letting the user control > > them, > > and worse: without keeping stability of guest-visible bits when > > upgrading Qemu or the host kernel. And that's what machine-types > > are > > for: to have sane defaults to be used as base.) > > > > Let me give you a practical example: I had a bug report about > > improper > > CPU topology information[1]. After investigating it, I have found > > out > > that the "level" cpudef field is too low; CPU core topology > > information > > is provided on CPUID leaf 4, and most of the Intel CPU models on > > Qemu > > have level=2 today (I don't know why). So, Qemu is responsible for > > exposing CPU topology information set using '-smp' to the guest OS, > > but > > libvirt would have to be responsible for choosing a proper "level" > > value > > that makes that information visible to the guest. We can _allow_ > > libvirt > > to fiddle with these low-level bits, of course, but requiring every > > management layer to build this low-level information from scratch > > is > > just a recipe to waste developer time. > > > > (And I really hope that there's no plan to require all those > > low-level > > bits to appear as-is on the libvirt XML definitions. Because that > > would > > require users to read the Intel 64 and IA-32 Architectures Software > > Developer's Manual, or the AMD64 Architecture Programmer's Manual > > and > > BIOS and Kernel Developer's Guides, just to understand why > > something is > > not working on his Virtual Machine.) > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=689665 > > > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list