On Thu, Feb 13, 2014 at 08:02:34AM +0000, Wangyufei (James) wrote: > Hello, > > I find that the cpu model Westmere defined in recently qemu has the cupid CPUID_EXT_PCLMULQDQ, > but the cpu model Westmere defined in libvirt doesn't have it, SandyBridge defined in libvirt has it. In my opinion, > the same cpu model defined in qemu and libvirt should have the same cpuids, or there'll be some problem happened. > > First, am I right? Yes, partially. If it were the other way around, the user could miss the feature in the guest. This way it can only happen that the feature is in the guest even when the user didn't requested it (it's not if the user specified he doesn't want it there. Anyway, we should be consistent with what qemu offers, unfortunately qemu probably behaves the same way wrt machine models. If I'm reading the log correctly, PCLMULQDQ never was in Westmere, but Eduardo explicitely removes that feature in commit 56383703 from machine types pc <= 1.4. > Second, if I'm right, whose bug it is? Libvirt or qemu? That depends, but from a broader view there are bigger problems with cpu models we are facing and Eduardo and Jiri are working on a full qemu introspection about models so we can fix these and many more similar problems. Maybe Jiri can shed some light into this particular "issue", but as I said, this way there's almost zero possibility of problems compared to the other option (if we add it into Westmere). Martin > > Thanks for your attention. > > Best Regards, > -WangYufei
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list