Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.
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.