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

[Yan Zhao]

On Mon, Oct 12, 2026 at 06:15:57AM -0700, Sean Christopherson wrote:
> 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.
Ah. I see.
I didn't realize it was seen a bug. I thought it was something we could improve
later by returning KVM_EXIT* instead.

> > 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.
Hmm. I knew QEMU handles KVM_EXIT_SHUTDOWN, but I wasn't sure if every VMM does.
So, a brute-force way was chosen :)