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