Re: [libvirt] possible bug regarding cpu flag 'pclmulqdq' in cpu_map.xml
On Thu, Apr 09, 2015 at 17:28:40 +0200, Sven Kieske wrote:
Hi,
laine on IRC was so kind to redirect me to this list, so
I didn't file a BZ at:
https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools
&component=libvirt
yet.
Please keep me CC'ed as I'm not subscribed to the list.
So here is my bug report:
Description of problem:
I believe the flag "pclmulqdq" is wrongly spelled in cpu_map.xml
Yes.
leading to wrong cpu being detected:
No.
And now, with a bit more details. The flag is misspelled because it was
originally added to QEMU with the wrong name. They added the correct
spelling since then (the old spelling is still supported by an alias)
but we don't support aliases and need to maintain backward
compatibility, which is why we are stuck with the wrong spelling.
However, the feature name does not really matter, it's only used for
human interaction. When checking features supported by a host CPUs,
libvirt uses CPUID bits.
Version-Release number of selected component (if applicable):
current master:
https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/cpu/cpu_map.xml;h=21
10c0b9b2a2a70f0334b2ff63416bd1b704b669;hb=HEAD
How reproducible:
always
Steps to Reproduce:
1.install e.g. ovirt, or some other libvirt consumer on a system with
a cpu like intel xeon E3-1230
2. it will get reported as nehalem
3.
Actual results:
cpu gets reported as "nehalem"
Expected results:
cpu gets reported as "sandy bridge"
This is likely because of some other feature is missing. SandyBridge CPU
model requires the following features to be supported (on top of those
supported by Nehalem): aes, pclmuldq, x2apic, tsc-deadline, xsave, avx,
rdtscp.
Jirka