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-kvmAssignee: Eduardo Habkost <ehabkost>
Status: CLOSED ERRATA QA Contact: liunana <nanliu>
Severity: high Docs Contact:
Priority: high    
Version: 7.6CC: 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
Fix included in qemu-kvm-1.5.3-165.el7

Comment 20 Yumei Huang 2019-05-29 08:55:04 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

Comment 21 Eduardo Habkost 2019-05-29 22:29:20 UTC
(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

Comment 22 Yumei Huang 2019-05-30 11:14:53 UTC
(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.

Comment 26 Yumei Huang 2019-06-18 09:36:42 UTC
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!

Comment 27 Eduardo Habkost 2019-06-19 15:23:02 UTC
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.

Comment 28 Yumei Huang 2019-06-20 02:24:28 UTC
Thanks Eduardo.

Moving to verified per above comments.

Comment 30 errata-xmlrpc 2019-08-06 12:41:58 UTC
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