[libvirt] possible bug regarding cpu flag 'pclmulqdq' in cpu_map.xml
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 leading to wrong cpu being detected: 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" Additional info: I found no real info on this flag: grep --color pclmuldq /usr/share/libvirt/cpu_map.xml <feature name='pclmuldq'> <feature name='pclmuldq'/> <feature name='pclmuldq'/> wikipedia (not always right, I know) and Intel just seem to know the flag 'pclmulqdq' See: https://en.wikipedia.org/wiki/CLMUL_instruction_set https://en.wikipedia.org/wiki/CPUID#EAX.3D1:_Processor_Info_and_Feature_ Bits https://software.intel.com/file/36945 But the Intel documentation is vast and I might have missed information on their website. So please check if this is the correct cpu flag indeed. Thanks! PS: If this is a real bug, it goes way back into el6 released versions of libvirt, and I would like to see a backport, if possible! Here is the BZ which introduced the flag: https://bugzilla.redhat.com/show_bug.cgi?id=761005 I guess this got wrongly typed, when you look at this comment, which has the correct notation: https://bugzilla.redhat.com/show_bug.cgi?id=761005#c16 - -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVJpqoAAoJEMby9TMDAbQRFlcP/1xajVdbv3fNfQPzJ3wIRa6M szkdbqMkI7HZTBjGvgSFXcf/ufb2RNfCU7AXpMi+FsE+oMB6qafke/J5VM6H/GUW TWuOy1wXz6QLxkP/p0VeU6ZX28XmwPOUMPcCQVhexIAbrmpgYCY42iaiEZUStcNp QQIqapOR6kL57WazTjY0U5GlGkV479oYlStF3E4maaJz+viNUqD6pE3WhXTbpcsu 1U1hPYANkfaMiXglm4MqpLklHw2PqgSfRvPzH58JStByuizPiWXZ9h42xE5ykVkW B7sw4XBSVk0mH99LNwnXC/VIw4pPz7uecTSbxdubZ/p4vvlG8JdszOekMfZVhy1+ ic93VPB+jSbiRGjWx8jkyYAsVOREaPBbmFF3ioLkAo9eVl8v8MXcBNppQQASVv7R vidSBu4qAVeu3ghmY5L+zEqTT3cG8pDcqzrFcELOtY1b6qsOOksgUxiylFv25g6F QPoDZpkpTvJ8YjOZx4H3ZjlfPQBhvBqd3QESNR8fKBUcxgxfGRwBVVU+14otvElE buEhBux0DvEfYrLbbiJtlGFtBmuz28RToPM1bmj52ujnGS1+0xYYYrHL35GhwnPc pvJ8mxAIRMYTdhn5eMsIh50N3uxz9Zky0CU8DJZ5St2Fsds3n7fR7Oao+PXOsOX1 mtJPsI1bYnxJ4RYVaIzk =ergB -----END PGP SIGNATURE-----
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
On 10/04/15 10:31, Jiri Denemark wrote:
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.
Thanks for this background information, in fact, this cpu misses the "aes" flag somehow. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
participants (2)
-
Jiri Denemark -
Sven Kieske