Re: [PATCH v2 2/3] KVM: TDX: Synthesize SHUTDOWN instead of returning -EIO on unhandled EPT violation

[Sean Christopherson <seanjc@google.com>]

On Sat, Oct 10, 2026, Yan Zhao wrote:
> On Tue, Sep 29, 2026 at 05:11:26PM -0700, Sean Christopherson wrote:
> > Exit to userspace with KVM_EXIT_SHUTDOWN instead of returning -EIO from
> > KVM_RUN if KVM encounters an EPT Violation due to a guest access to a
> > pending page.  Returning -EIO implies KVM is buggy, and most VMMs will
> > respond by completely terminating the VM, versus rebooting the VM in
> > response to KVM_EXIT_SHUTDOWN.  I.e. give the VMM the option of trying to
> > keep the VM (from the end user's perspective) alive.
> > 
> > Ideally, KVM would probably exit with KVM_EXIT_MEMORY_FAULT, but KVM would
> > need to extend run->memory_fault so that userspace knows the fault can't be
> > handled.  This scenario specifically occurs when the guest has deliberately
> > disabled #VEs on unaccepted memory for security purposes, i.e. the guest
> > literally disabled the mechanism that tells it it screwed up.  But, because
> > this is fatal, and the whole point is to NOT try to fixup the fault,
> > jumping through hoops to return MEMORY_FAULT instead of SHUTDOWN doesn't
> > make a whole lot of sense.
> > 
> > Don't bother bouncing through KVM_REQ_TRIPLE_FAULT as
> > tdx_handle_ept_violation() is a top-level exit handler, i.e. there is no
> > need to worry about failing to actually exit to userspace.
> > 
> > Fixes: e6a85781f783 ("KVM: TDX: Detect unexpected SEPT violations due to pending SPTEs")
> > Cc: stable@vger.kernel.org
> > Cc: James Houghton <jthoughton@google.com>
> > Cc: Xiaoyao Li <xiaoyao.li@intel.com>
> > Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > Cc: Yan Zhao <yan.y.zhao@intel.com>
> > Cc: Binbin Wu <binbin.wu@linux.intel.com>
> > Cc: Ackerley Tng <ackerleytng@google.com>
> > Cc: Vishal Annapurve <vannapurve@google.com>
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kvm/vmx/tdx.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> > index 29d4751f37fb..e3723f1222fc 100644
> > --- a/arch/x86/kvm/vmx/tdx.c
> > +++ b/arch/x86/kvm/vmx/tdx.c
> > @@ -1939,8 +1939,8 @@ static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu)
> >  		if (tdx_is_sept_violation_unexpected_pending(vcpu)) {
> >  			pr_warn("Guest access before accepting 0x%llx on vCPU %d\n",
> >  				gpa, vcpu->vcpu_id);
> > -			kvm_vm_dead(vcpu->kvm);
> > -			return -EIO;
> > +			kvm_prepare_shutdown_exit(vcpu);
> Would it be better to exit with the reason KVM_EXIT_SYSTEM_EVENT and type
> KVM_SYSTEM_EVENT_SHUTDOWN or KVM_SYSTEM_EVENT_TDX_FATAL?

No.  KVM_SYSTEM_EVENT_SHUTDOWN is an explicit call from the guest to do a clean
shutdown (used by arm64 and RISC-V).  KVM_SYSTEM_EVENT_TDX_FATAL similarly exists
to relay explicit calls from the guest.  Ditto for KVM_SYSTEM_EVENT_CRASH and
KVM_SYSTEM_EVENT_SEV_TERM (which obviously is a poor fit for TDX, just pointing
out that it's another guest-initiated event).

KVM_EXIT_SHUTDOWN isn't a perfect fit, but IMO it's the closest approximation,
e.g. it's a rough equivalent of what happens if a #VE couldn't be handled because
the stack is invalid.  And more importantly, because we're retroactively fixing
code, KVM_EXIT_SHUTDOWN has the best chance of being handled appropriately by all
VMMs.

> By defining a specific flag (e.g., KVM_SYSTEM_EVENT_FLAG_TDX_UNEXPECTED_PENDING),
> we can stuff necessary info like gpa, vcpu->vcpu_id into data, so both pr_warn()
> and pr_warn_ratelimited() can be dropped.

Well, IMO, the printk can be dropped no matter what. :-)  But I don't care _that_
much so I'm ok keeping the ratelimited version.

vcpu_id is redundant, the exit is tied to a specific vCPU.  And as I said elsewhere,
practically speaking the GPA is all but guaranteed to be useless outside of
interactive debug sessions.