Bug 1709495
Summary: | Change CPUID[0x40000000].EAX from 0 to KVM_CPUID_FE...ATURES (0x40000001) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Gajanan <gchakkar> |
Component: | qemu-kvm | Assignee: | Eduardo Habkost <ehabkost> |
Status: | CLOSED ERRATA | QA Contact: | liunana <nanliu> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.6 | CC: | ailan, chayang, ehabkost, jcoscia, jinzhao, juzhang, knoel, mrezanin, mtessun, qzhang, virt-maint, yuhuang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-1.5.3-165.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-06 12:41:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Comment 18
Miroslav Rezanina
2019-05-28 18:01:30 UTC
Test step: Check cpuid in guest by "cpuid -l 0x40000000 -r". With qemu-kvm-1.5.3-164.el7, eax is 0x00000000. # cpuid -l 0x40000000 -r CPU 0: 0x40000000 0x00: eax=0x00000000 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d CPU 1: 0x40000000 0x00: eax=0x00000000 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d CPU 2: 0x40000000 0x00: eax=0x00000000 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d CPU 3: 0x40000000 0x00: eax=0x00000000 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d With qemu-kvm-1.5.3-165.el7, eax is 0x40000001. # cpuid -l 0x40000000 -r CPU 0: 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d CPU 1: 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d CPU 2: 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d CPU 3: 0x40000000 0x00: eax=0x40000001 ebx=0x4b4d564b ecx=0x564b4d56 edx=0x0000004d Hi Eduardo, could you please help check if above test and verification is sufficient? I checked leaf 0x40000000 because I saw following statement in https://lwn.net/Articles/301888/, which is just a proposal, but I couldn't find the final official document. I was wondering if we have any official doc to describe the CPUID usage in KVM. " Hypervisor CPUID Information Leaf: Leaf 0x40000000. This leaf returns the CPUID leaf range supported by the hypervisor and the hypervisor vendor signature. # EAX: The maximum input value for CPUID supported by the hypervisor. # EBX, ECX, EDX: Hypervisor vendor ID signature. " Thanks, Yumei Huang (In reply to Yumei Huang from comment #20) > Hi Eduardo, could you please help check if above test and verification is > sufficient? Verification in comment #20 is sufficient to confirm the bug is fixed. However, I would like to ensure we will test multiple guest OSes after the fix is applied to be more confident we are not introducing any regression. How we can ensure this will be done? Should the QE team do it as part of the regular test plan, or as part of validation of this BZ? > I checked leaf 0x40000000 because I saw following statement in > https://lwn.net/Articles/301888/, which is just a proposal, but I couldn't > find the final official document. I was wondering if we have any official > doc to describe the CPUID usage in KVM. Official KVM CPUID documentation is in the Linux kernel source: https://www.kernel.org/doc/Documentation/virtual/kvm/cpuid.txt (In reply to Eduardo Habkost from comment #21) > (In reply to Yumei Huang from comment #20) > > Hi Eduardo, could you please help check if above test and verification is > > sufficient? > > Verification in comment #20 is sufficient to confirm the bug is fixed. > > However, I would like to ensure we will test multiple guest OSes after the > fix is applied to be more confident we are not introducing any regression. > How we can ensure this will be done? Should the QE team do it as part of > the regular test plan, or as part of validation of this BZ? > Yes, more function test will be performed as part of validation. The test in comment 20 just verifies that the change takes effect. Normally QE would do some feature test to ensure no regression introduced. Thanks. QE tested booting guest with different cpu models, including Skylake-Server-IBRS, Broadwell-IBRS, Haswell-IBRS, IvyBridge-IBRS, SandyBridge-IBRS, Opteron_G5, Opteron_G4, Opteron_G3, Opteron_G2, Opteron_G1, guest works well. And with flag 'check', for Opteron_G5, Opteron_G4, and Opteron_G2, got following warning: [qemu output] warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] For Opteron_G3, got warning: [qemu output] warning: host doesn't support requested feature: CPUID.01H:ECX.monitor [bit 3] [qemu output] warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] As for other cpu models, no warning at all. Host for amd cpu model test: AMD Opteron(tm) Processor 6376 Host for intel cpu model test: Intel(R) Xeon(R) Platinum 8260L CPU @ 2.40GHz qemu version: qemu-kvm-1.5.3-167.el7 kernel version: 3.10.0-1057.el7.x86_64 Hi Eduardo, Would you please help check if above tests plus comment 20 are enough to verify this bug? Thanks! The warnings in comment #26 are known issues in the RHEL-7 tree. The validation is comment #20 is enough to consider the bug fixed. Thanks Eduardo. Moving to verified per above comments. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:2078 |