On Wed, Sep 23, 2020 at 9:51 AM Sean Christopherson <[email protected]> wrote: > > If PCID is not exposed to the guest, clear INVPCID in the guest's CPUID > even if the VMCS INVPCID enable is not supported. This will allow > consolidating the secondary execution control adjustment code without > having to special case INVPCID. > > Technically, this fixes a bug where !CPUID.PCID && CPUID.INVCPID would > result in unexpected guest behavior (#UD instead of #GP/#PF), but KVM > doesn't support exposing INVPCID if it's not supported in the VMCS, i.e. > such a config is broken/bogus no matter what. > > Signed-off-by: Sean Christopherson <[email protected]> > --- > arch/x86/kvm/vmx/vmx.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index cfed29329e4f..57e48c5a1e91 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -4149,16 +4149,22 @@ static void vmx_compute_secondary_exec_control(struct > vcpu_vmx *vmx) > } > } > > + /* > + * Expose INVPCID if and only if PCID is also exposed to the guest. > + * INVPCID takes a #UD when it's disabled in the VMCS, but a #GP or > #PF > + * if CR4.PCIDE=0. Enumerating CPUID.INVPCID=1 would lead to > incorrect > + * behavior from the guest perspective (it would expect #GP or #PF). > + */ > + if (!guest_cpuid_has(vcpu, X86_FEATURE_PCID)) > + guest_cpuid_clear(vcpu, X86_FEATURE_INVPCID); > +
I thought the general rule for userspace provided CPUID bits was that kvm only made any adjustments necessary to prevent bad things from happening at the host level. Proper guest semantics are entirely the responsibility of userspace. Or did I misunderstand?
