On Fri, Sep 30, 2022 at 2:21 PM Dong, Eddie <eddie.dong@xxxxxxxxx> wrote:
>
>
>
> > -----Original Message-----
> > From: Jim Mattson <jmattson@xxxxxxxxxx>
> > Sent: Thursday, September 29, 2022 3:52 PM
> > To: kvm@xxxxxxxxxxxxxxx; pbonzini@xxxxxxxxxx; Christopherson,, Sean
> > <seanjc@xxxxxxxxxx>
> > Cc: Jim Mattson <jmattson@xxxxxxxxxx>
> > Subject: [PATCH 2/6] KVM: x86: Mask off reserved bits in CPUID.80000006H
> >
> > KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
> > actually supports. CPUID.80000006H:EDX[17:16] are reserved bits and should
> > be masked off.
> >
> > Fixes: 43d05de2bee7 ("KVM: pass through CPUID(0x80000006)")
> > Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx>
> > ---
> > arch/x86/kvm/cpuid.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index
> > ea4e213bcbfb..90f9c295825d 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -1125,6 +1125,7 @@ static inline int __do_cpuid_func(struct
> > kvm_cpuid_array *array, u32 function)
> > break;
> > case 0x80000006:
> > /* L2 cache and TLB: pass through host info. */
> > + entry->edx &= ~GENMASK(17, 16);
>
> SDM of Intel CPU says the edx is reserved=0. I must miss something.
This is an AMD defined leaf. Therefore, the APM is authoritative.
> BTW, for those reserved bits, their meaning is not defined, and the VMM should not depend on them IMO.
> What is the problem if hypervisor returns none-zero value?
The problem arises if/when the bits become defined in the future, and
the functionality is not trivially virtualized.
> Thanks Eddie
>
> > break;
> > case 0x80000007: /* Advanced power management */
> > /* invariant TSC is CPUID.80000007H:EDX[8] */
> > --
> > 2.38.0.rc1.362.ged0d419d3c-goog
>
