Re: [PATCH v2 0/3] KVM: TDX: Syntehsize SHUTDOWN on unhandled EPT Violation

[Sean Christopherson]

On Sat, Oct 10, 2026, Yan Zhao wrote:
> On Fri, Oct 09, 2026 at 01:58:04PM -0700, Sean Christopherson wrote:
> > On Thu, Oct 08, 2026, Yan Zhao wrote:
> > > On Tue, Sep 29, 2026 at 05:55:11PM -0700, Sean Christopherson wrote:
> > > > On Wed, Sep 30, 2026, Rick P Edgecombe wrote:
> > > > > On Tue, 2026-09-29 at 17:11 -0700, Sean Christopherson wrote:
> > > > > > Signal SHUTDOWN instead of -EIO if the guest accesses an unaccepted page and
> > > > > > has disabled EPT Violation #VEs on such accesses.  Returning -EIO is all but
> > > > > > guaranteed to mislead the VMM into thinking KVM (or the VMM) messed up, and
> > > > > > will likely result in the VM being terminated instead of rebooted.
> > > Hmm, it's by design in my previous implementation to terminate a VM when the
> > > guest accesses an unaccepted page and has disabled EPT Violation #VEs on such
> > > accesses, according to the TDX module spec:
> > > 
> > > "This happens if the TD is configured to TD-exit (instead of a #VE) on an EPT
> > >  violation due to accessing a PENDING page. It normally indicates an error
> > >  condition; the host VMM may decide to tear the TD down."
> > > 
> > > So, for the initial implementation, we chose to invoke kvm_vm_dead() and print
> > > out the exact reason as a hint to the system admin.
> > 
> > kvm_vm_dead() should only be used when KVM *needs* to prevent userspace from
> > running the VM.
> Ok. But my previous intention was to kill the VM regardless of whether the
> userspace handles KVM_EXIT_SHUTDOWN or not.
> Did I use it correctly?

No.  Returning -EIO kills not only what KVM sees as the VM, it often kills what
the end user, i.e. the customer in our case, see as the VM.

> I'm asking because you added the Fixes tag and "Cc: stable@xxxxxxxxxxxxxxx" for
> patches 1/2 as well.
> 
> > > (Previously, reboot was also not supported for a TDX guest).
> > 
> > But QEMU isn't KVM.  While QEMU is the de facto reference VMM, it's important to
> > keep in mind that it's not the only VMM (and that's not just about Google's VMM,
> > there are plenty of other non-QEMU VMMs that are used in production environments).
> Hmm. That was the reason for me to choose forcefully killing the VM inside KVM,
> since for the initial implementation, I didn't want to bother updating every
> VMM :)

Why would any VMM need to be updated?  VMMs already need to handle KVM_EXIT_SHUTDOWN
for TDX VMs.