I see. Thanks Jim!
It makes sense.
Eddie
> -----Original Message-----
> From: Jim Mattson <jmattson@xxxxxxxxxx>
> Sent: Tuesday, October 4, 2022 7:59 PM
> To: Dong, Eddie <eddie.dong@xxxxxxxxx>
> Cc: kvm@xxxxxxxxxxxxxxx; pbonzini@xxxxxxxxxx; Christopherson,, Sean
> <seanjc@xxxxxxxxxx>
> Subject: Re: [PATCH 2/6] KVM: x86: Mask off reserved bits in
> CPUID.80000006H
>
> On Tue, Oct 4, 2022 at 5:08 PM Dong, Eddie <eddie.dong@xxxxxxxxx> wrote:
> >
> > > Hardware reserved CPUID bits are always zero today, though that may
> > > not be architecturally specified.
> >
> > entry->edx is initialized to native value in do_host_cpuid(), which executes
> physical CPUID.
> > I guess I am disconnected here.
>
> Hardware values should only be passed through for features that KVM can
> support. Reserved bits should be set to 0, because KVM has no idea whether
> or not it will be able to support them once they are defined.
>
> Perhaps an example will help.
>
> At one time, leaf 7 was completely reserved. Following the principle that KVM
> should not pass through reserved CPUID bits, KVM zeroed out this leaf prior to
> commit 611c120f7486 ("KVM: Mask function7 ebx against host capability
> word9").
> Suppose that the legacy KVM had, as you suggest, passed through the
> hardware values for leaf 7. As CPUs appeared with SMEP, SMAP, Intel
> Processor Trace, SGX, and a whole slew of other features, that version of KVM
> would claim that it supported those features. Not true.
>
> How would userspace be able to tell a version of KVM that could really support
> SMEP from one that just blindly passed the bit through without knowing what
> it meant? The KVM_GET_SUPPORTED_CPUID results would be identical.
>
> In some cases, if KVM claims to support a feature that it doesn't (like SMEP), a
> guest that tries to use the feature will fail to boot (e.g. setting CR4.SMEP will
> raise an unexpected #GP).
>
> However, as you alluded to earlier, zeroing out reserved bits does not always
> work out. Again, looking at leaf 7, the old KVM that clears all of leaf 7 claims
> legacy x87 behavior with respect to the FPU data pointer, FPU CS and FPU DS
> values, even on newer chips where that is not true. This is because of the two
> "reverse polarity" feature bits in leaf 7, where '0' indicates the presence of the
> feature and '1'
> indicates that the feature has been removed. At least, in this case, userspace
> can tell if KVM is wrong, just by querying CPUID leaf 7 itself. Long after leaf 7
> support was added to KVM, it continued to make the mistake of clearing those
> two bits. That bug wasn't addressed until commit e3bcfda012ed ("KVM: x86:
> Report deprecated x87 features in supported CPUID"). Fortunately, no
> software actually looks at those two bits.
>
> The KVM_GET_SUPPORTED_CPUID API is abysmal, but it is what we have for
> now. The best thing we can do is to zero out reserved bits. Passing through the
> hardware values is likely to get us into trouble in the future, when those bits
> are defined to mean something that we don't support.
