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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list