Description of problem: The feature pclmulqdq (also called pclmuldq ) was introduced in Intel Westmere: http://en.wikipedia.org/wiki/Westmere_%28microarchitecture%29 It is visible on the hypervisor but not on guests. According to kbase: https://access.redhat.com/solutions/634853 it was introduced in libvirt on Sandybridge. Also according to the /usr/share/libvirt/cpu_map.xml file on the hypervisor it was introduced on Sandybridge, but not Westmere. Seems like libvirt is missing this cpu feature for Westmere. Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. On a Westmere cpu setup a guest. 2. on the guest check /proc/cpuinfo and the pclmulqdq feature is missing 3. Actual results: pclmulqdq is missing from /proc/cpuinfo on guests. Expected results: pclmulqdq feateure to be in /proc/cpuinfo Additional info: The feature works fine if using a Sandybridge CPU.
FYI, Openssl benchmark from VM on virtual "Intel Westmere" cpu: $ openssl speed -elapsed -evp aes-128-gcm <snip> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 113571.02k 167553.62k 213578.07k 241615.87k 191804.76k And directly on the hypervisor this VM is running on: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 219934.48k 409803.03k 616356.52k 661049.69k 633790.46k
*** Bug 1150598 has been marked as a duplicate of this bug. ***
There's one more issue on top of what I already wrote upstream. While upstream QEMU enabled the feature in Westmere CPU model, RHEL QEMU has Westmere without this feature so adding it to the appropriate libvirt CPU model would not have any visible effect. Moreover, explicitly adding <feature name='pclmuldq' policy='require'/> would not work either since libvirt would think the feature is already in Westmere CPU model. In other words, the request to add the feature to Westmere should actually be filed against qemu-kvm. However, adding it would mean Westmere in rhel-6.7.0 machine type would be different from Westmere in any older machine type. While libvirt does not really care at the moment, all VMs would have to be updated to use the new machine type to be able to see the new feature.
Moving to qemu component per comment 3.
Upstream fix: commit 41cb383f42d0cb51d8e3e25e3ecebc954dd4196f Author: Aurelien Jarno <aurelien> Date: Sun Mar 31 12:58:30 2013 +0200 target-i386: enable PCLMULQDQ on Westmere CPU The PCLMULQDQ instruction has been introduced on the Westmere CPU. Reviewed-by: Richard Henderson <rth> Reviewed-by: Edgar E. Iglesias <edgar.iglesias> Signed-off-by: Aurelien Jarno <aurelien>
There are two possible workarounds for this bug, that should be simple and won't require a machine-type update: First workaround: Use the Nehalem CPU model, and manually enable the following features: aes, pclmulqdq. The only guest-visible side-effect is that CPUID level, model, and stepping will be different from the Westmere CPU model, but I don't believe this should cause any issue. Second workaround: Use the SandyBridge CPU model, and manually disable the following features: avx, xsave, tsc-deadline, x2apic, rdtscp. The level, model, and stepping CPUID values will also be different, but in this case this shouldn't cause any issue either. Please let us know if any of those workarounds fix the issue.
*** Bug 1150418 has been marked as a duplicate of this bug. ***