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

[Yan Zhao <yan.y.zhao@intel.com>]

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?
I'm asking because you added the Fixes tag and "Cc: stable@vger.kernel.org" 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 :)

> > Returning -EIO was based on the following considerations:
> > - vcpu_enter_guest() returns -EIO when kvm_test_request(KVM_REQ_VM_DEAD, vcpu)
> >   is true.
> > - A request to handle a specific EPT violation is rejected by the firmware (the
> >   TDX module).
> > 
> > > > I'm pretty sure Yan had a test for this path, and I'd love to see it actually
> > > > exercised. What is the urgency on getting this fix upstream? Can we wait a week?
> > I triggered the EPT violation in the kexec path, and successfully had the TD
> > - killed with error msg: "qemu-system-x86_64: cpus are not resettable,
> >   terminating" on an old QEMU, or
> > - rebooted on a new QEMU with the msg printed:
> >   "qemu-system-x86_64: info: virtual machine state has been rebuilt with new
> >    guest file handle".
> > 
> > The TDX selftests we are using do not handle KVM_EXIT_SHUTDOWN, so if such
> > an error occurs, it's silently ignored by the TDX selftests even with msg
> > "kvm_intel: Guest access before accepting 0x8000c000 on vCPU 1" printed in dmesg.
> 
> If TDX selftests don't fail due to an unexpected KVM_EXIT_SHUTDOWN, then that needs
> to be fixed irrespective of this change.
Ok.

> > > Absolutely.  It can probably wait a month and no one would care.  IIRC, this got
> > > hit by someone (internal to Google) deliberately crashing a guest kernel and doing
> > > funky things with kexec.  It showed up on my radar purely because our automated
> > > madness alerted on the resulting assertion (on -EIO) in the VMM.
> > Though I didn't realize that returning -EIO would mislead the VMM into thinking
> > KVM (or the VMM) messed up, such an error could also be introduced by a VMM bug?
> 
> Yes, but that holds true for literally every guest failure.  It's like saying that
> all observed errors could be due to a CPU bug, e.g. because the CPU corrupted state
> or because a bit flipped in DRAM.  It's technically true, but in practice the vast
> majority of failures (outside of pre-production hardware) are software errors, and
> so absent evidence that a hardware/VMM/KVM bug is at play, KVM shouldn't assume
> anything.  I.e. as above, unless KVM needs to protect itself, KVM should aways try
> to provide semantics that are rooted in the CPU architecture.
> 
> E.g. an analogous failure would for non-TDX guests would be if the host zeroed a
> page that happened to be necessary to handle exceptions in the guest, and as a
> result the guest hit a triple fault shutdown.  KVM doesn't return -EIO instead of
> KVM_EXIT_SHUTDOWN just because the failure could have been introduced by a kernel
> or VMM bug.
Makes sense. Thanks for the explanation!

> > e.g., VMM removes an accepted page without any notification to the TD configured
> > with TDX_TD_ATTRIBUTES_SEPT_VE_DISABLE bit.