Bug 1709495 - Change CPUID[0x40000000].EAX from 0 to KVM_CPUID_FE...ATURES (0x40000001)
Summary: Change CPUID[0x40000000].EAX from 0 to KVM_CPUID_FE...ATURES (0x40000001)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.6
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Eduardo Habkost
QA Contact: Yumei Huang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-13 17:21 UTC by Gajanan
Modified: 2019-08-06 12:42 UTC (History)
12 users (show)

Fixed In Version: qemu-kvm-1.5.3-165.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 12:41:58 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2078 None None None 2019-08-06 12:42:27 UTC

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


Note You need to log in before you can comment on or make changes to this bug.