Re: [PATCH] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL

[Sean Christopherson <seanjc@google.com>]

On Wed, Oct 15, 2025, Xiaoyao Li wrote:
> On 10/15/2025 9:57 PM, Sean Christopherson wrote:
> > On Wed, Oct 15, 2025, Xiaoyao Li wrote:
> > > On 10/15/2025 7:10 AM, Sean Christopherson wrote:
> > > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> > > > index 76271962cb70..f64a1eb241b6 100644
> > > > --- a/arch/x86/kvm/vmx/nested.c
> > > > +++ b/arch/x86/kvm/vmx/nested.c
> > > > @@ -6728,6 +6728,14 @@ static bool nested_vmx_l1_wants_exit(struct kvm_vcpu *vcpu,
> > > >    	case EXIT_REASON_NOTIFY:
> > > >    		/* Notify VM exit is not exposed to L1 */
> > > >    		return false;
> > > > +	case EXIT_REASON_SEAMCALL:
> > > > +	case EXIT_REASON_TDCALL:
> > > > +		/*
> > > > +		 * SEAMCALL and TDCALL unconditionally VM-Exit, but aren't
> > > > +		 * virtualized by KVM for L1 hypervisors, i.e. L1 should
> > > > +		 * never want or expect such an exit.
> > > > +		 */
> > > 
> > > The i.e. part is confusing? It is exactly forwarding the EXITs to L1, while
> > > it says L1 should never want or expect such an exit.
> > 
> > Gah, the comment is right, the code is wrong.
> 
> So the intent was to return false here? to let L0 handle the exit?

Correct.

> Then I have a question, why not implement it in nested_vmx_l0_wants_exit()?
> what's the reason and rule here?

The basic gist of "l0/l1 wants exit" is that each entity (L0 and L1) should act
independently.  And if both L0 and L1 "want" the exit, then L0 wins.

E.g. for EXIT_REASON_EXTERNAL_INTERRUPT, KVM _always_ wants the exit because KVM
unconditionally runs with PIN_BASED_EXT_INTR_MASK set.  But L1 might want the
exit too, i.e. if it too is running with PIN_BASED_EXT_INTR_MASK.  But L1 doesn't
get the exit because L0's desire trumps L1.

Other exit are less straightfoward.  E.g. EXIT_REASON_EXCEPTION_NMI is filled with
conditionals because KVM needs to determine if the exception was due to something
KVM did, i.e. if the exception needs to be resolved by KVM, or if it the exception
isn't at all related to KVM and thus isn't "want" by L0.  But the exception may
still be routed to L0, e.g. if L1 doesn't want it.

For this particular case, L1 _can't_ want the exit, because the exit simply shouldn't
exist from L1's perspective.  Whether or not L0 wants the exit can't really be
known, because that would require predicting the future.  E.g. in the unlikely
case that KVM somehow virtualized some piece of TDX and thus exposed SEAMCALL
and/or TDCALL exits to L1, then nested_vmx_l1_wants_exit() _must_ be updated,
if only to consult the L1 VMXON state.  But L0's wants may or may not change;
if there are no scenarios where KVM/L0 "wants" the exit, then there wouldn't be
a need to modify nested_vmx_l0_wants_exit().

And so the most future-resistant location for this particular case is
nested_vmx_l1_wants_exit().