Re: [RFC PATCH 06/18] KVM: VMX: Wire up Intel MBEC enable/disable logic

["Shah, Amit" <Amit.Shah@amd.com>]

On Tue, 2025-05-13 at 06:28 -0700, Sean Christopherson wrote:
> On Tue, May 13, 2025, Jon Kohler wrote:
> > > On May 12, 2025, at 2:23 PM, Sean Christopherson
> > > <seanjc@google.com> wrote:
> > > > On Thu, Mar 13, 2025, Jon Kohler wrote:
> > > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > > > index 7a98f03ef146..116910159a3f 100644
> > > > --- a/arch/x86/kvm/vmx/vmx.c
> > > > +++ b/arch/x86/kvm/vmx/vmx.c
> > > > @@ -2694,6 +2694,7 @@ static int setup_vmcs_config(struct
> > > > vmcs_config *vmcs_conf,
> > > > return -EIO;
> > > > 
> > > > vmx_cap->ept = 0;
> > > > + _cpu_based_2nd_exec_control &=
> > > > ~SECONDARY_EXEC_MODE_BASED_EPT_EXEC;
> > > > _cpu_based_2nd_exec_control &=
> > > > ~SECONDARY_EXEC_EPT_VIOLATION_VE;
> > > > }
> > > > if (!(_cpu_based_2nd_exec_control & SECONDARY_EXEC_ENABLE_VPID)
> > > > &&
> > > > @@ -4641,11 +4642,15 @@ static u32
> > > > vmx_secondary_exec_control(struct vcpu_vmx *vmx)
> > > > exec_control &= ~SECONDARY_EXEC_ENABLE_VPID;
> > > > if (!enable_ept) {
> > > > exec_control &= ~SECONDARY_EXEC_ENABLE_EPT;
> > > > + exec_control &= ~SECONDARY_EXEC_MODE_BASED_EPT_EXEC;
> > > > exec_control &= ~SECONDARY_EXEC_EPT_VIOLATION_VE;
> > > > enable_unrestricted_guest = 0;
> > > > }
> > > > if (!enable_unrestricted_guest)
> > > > exec_control &= ~SECONDARY_EXEC_UNRESTRICTED_GUEST;
> > > > + if (!enable_pt_guest_exec_control)
> > > > + exec_control &= ~SECONDARY_EXEC_MODE_BASED_EPT_EXEC;
> > > 
> > > This is wrong and unnecessary.  As mentioned early, the input
> > > that matters is
> > > vmcs12.  This flag should *never* be set for vmcs01.
> > 
> > I’ll page this back in, but I’m like 75% sure it didn’t work when I
> > did it that way.
> 
> Then you had other bugs.  The control is per-VMCS and thus needs to
> be emulated
> as such.  Definitely holler if you get stuck, there's no need to
> develop this in
> complete isolation.

Looking at this from the AMD GMET POV, here's how I think support for
this feature for a Windows guest would be implemented:

* Do not enable the GMET feature in vmcb01.  Only the Windows guest (L1
guest) sets this bit for its own guest (L2 guest).  KVM (L0) should see
the bit set in vmcb02 (and vmcb12).  OTOH, pass on the CPUID bit to the
L1 guest.

* KVM needs to propagate the #NPF to Windows (instead of handling
anything itself -- ie no shadow page table adjustments or walks
needed).  Windows spawns an L2 guest that causes the #NPF, and Windows
is the one that needs to consume that fault.

* KVM needs to differentiate an #NPF exit due to GMET or non-GMET
condition -- check the CPL and U/S bits from the exit, and the NX bit
from the PTE that faulted.  If due to GMET, propagate it to the guest.
If not, continue handling it

(btw KVM MMU API question -- from the #NPF, I have the GPA of the L2
guest.  How to go from that guest GPA to look up the NX bit for that
page?  I skimmed and there doesn't seem to be an existing API for it -
so is walking the tables the only solution?)

		Amit