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

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

[Sean Christopherson]

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.

v2: 
 - Return SHUTDOWN directly, via a new helper. [Rick]
 - Ratelimit the error message. [Sashiko, (and past me, amusingly)]

v1: https://lore.kernel.org/all/20260923163315.1580860-1-seanjc@google.com

Sean Christopherson (3):
  KVM: x86: Add a helper to prepare vcpu->run for a SHUTDOWN exit to
    userspace
  KVM: TDX: Synthesize SHUTDOWN instead of returning -EIO on unhandled
    EPT violation
  KVM: TDX: Ratelimit the "EPT Violation on pending acceptance page"
    warning

 arch/x86/kvm/svm/svm.c   |  3 +--
 arch/x86/kvm/vmx/tdx.c   | 11 +++++------
 arch/x86/kvm/vmx/vmx.c   |  3 +--
 arch/x86/kvm/x86.c       |  3 +--
 include/linux/kvm_host.h |  8 ++++++++
 5 files changed, 16 insertions(+), 12 deletions(-)


base-commit: a0bc8e1d7a82bb143b8f8f44ae3a01938f37c2ea
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

[PATCH v2 1/3] KVM: x86: Add a helper to prepare vcpu->run for a SHUTDOWN exit to userspace

[Sean Christopherson]

Add kvm_prepare_shutdown_exit() to dedup the paths that exit to userspace
with KVM_EXIT_SHUTDOWN, all of which happen to be x86 (presumably other
architectures use KVM_EXIT_SYSTEM_EVENT?).

Note, this adds a clearing of mmio_needed for SVM's shutdown_interception().
Not clearing mmio_needed in that case is all but guaranteed to be benign;
KVM should never enter the guest with outstanding emulated MMIO operations
(the equivalent VMX and TDX paths likely copy+pasted the code from
KVM_REQ_TRIPLE_FAULT, which does need to clear mmio_needed as KVM can
synthesize a triple fault shutdown in the middle of instruction emulation).

Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/svm/svm.c   | 3 +--
 arch/x86/kvm/vmx/tdx.c   | 3 +--
 arch/x86/kvm/vmx/vmx.c   | 3 +--
 arch/x86/kvm/x86.c       | 3 +--
 include/linux/kvm_host.h | 8 ++++++++
 5 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 0eb1623052c1..d2feb57d774f 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2190,7 +2190,6 @@ static int mc_interception(struct kvm_vcpu *vcpu)
 
 static int shutdown_interception(struct kvm_vcpu *vcpu)
 {
-	struct kvm_run *kvm_run = vcpu->run;
 	struct vcpu_svm *svm = to_svm(vcpu);
 
 
@@ -2214,7 +2213,7 @@ static int shutdown_interception(struct kvm_vcpu *vcpu)
 		kvm_vcpu_reset(vcpu, true);
 	}
 
-	kvm_run->exit_reason = KVM_EXIT_SHUTDOWN;
+	kvm_prepare_shutdown_exit(vcpu);
 	return 0;
 }
 
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index ee1d412b0ee6..29d4751f37fb 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -2092,8 +2092,7 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
 
 	switch (exit_reason.basic) {
 	case EXIT_REASON_TRIPLE_FAULT:
-		vcpu->run->exit_reason = KVM_EXIT_SHUTDOWN;
-		vcpu->mmio_needed = 0;
+		kvm_prepare_shutdown_exit(vcpu);
 		return 0;
 	case EXIT_REASON_EXCEPTION_NMI:
 		return tdx_handle_exception_nmi(vcpu);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index dc635145eeaf..35db7197c586 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -5588,8 +5588,7 @@ static __always_inline int handle_external_interrupt(struct kvm_vcpu *vcpu)
 
 static int handle_triple_fault(struct kvm_vcpu *vcpu)
 {
-	vcpu->run->exit_reason = KVM_EXIT_SHUTDOWN;
-	vcpu->mmio_needed = 0;
+	kvm_prepare_shutdown_exit(vcpu);
 	return 0;
 }
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cf3fcdfd8ad2..cffd1b6ef789 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8139,8 +8139,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
 				kvm_nested_call(triple_fault)(vcpu);
 
 			if (kvm_check_request(KVM_REQ_TRIPLE_FAULT, vcpu)) {
-				vcpu->run->exit_reason = KVM_EXIT_SHUTDOWN;
-				vcpu->mmio_needed = 0;
+				kvm_prepare_shutdown_exit(vcpu);
 				r = 0;
 				goto out;
 			}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a836756baebb..02ca5d5d83b5 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2522,6 +2522,14 @@ static inline void kvm_account_pgtable_pages(void *virt, int nr)
 /* Max number of entries allowed for each kvm dirty ring */
 #define  KVM_DIRTY_RING_MAX_ENTRIES  65536
 
+static inline void kvm_prepare_shutdown_exit(struct kvm_vcpu *vcpu)
+{
+	vcpu->run->exit_reason = KVM_EXIT_SHUTDOWN;
+#ifdef CONFIG_HAS_IOMEM
+	vcpu->mmio_needed = 0;
+#endif
+}
+
 static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
 						 gpa_t gpa, gpa_t size,
 						 bool is_write, bool is_exec,
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

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

[Sean Christopherson]

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);
+			return 0;
 		}
 		/*
 		 * Always treat SEPT violations as write faults.  Ignore the
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

[PATCH v2 3/3] KVM: TDX: Ratelimit the "EPT Violation on pending acceptance page" warning

[Sean Christopherson]

Ratelimit TDX's kernel logging when a guest accesses an unaccepted page and
has opted to disable EPT Violation #VEs for unaccepted accesses, as the
pr_warn() is trivial for a misbehaving userspace to trigger.

Fixes: e6a85781f783 ("KVM: TDX: Detect unexpected SEPT violations due to pending SPTEs")
Cc: stable@vger.kernel.org
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260923164348.2DB2D1F000FF@smtp.kernel.org
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 e3723f1222fc..4cac43299851 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -1937,8 +1937,8 @@ static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu)
 
 	if (vt_is_tdx_private_gpa(vcpu->kvm, gpa)) {
 		if (tdx_is_sept_violation_unexpected_pending(vcpu)) {
-			pr_warn("Guest access before accepting 0x%llx on vCPU %d\n",
-				gpa, vcpu->vcpu_id);
+			pr_warn_ratelimited("Guest access before accepting 0x%llx on vCPU %d\n",
+					    gpa, vcpu->vcpu_id);
 			kvm_prepare_shutdown_exit(vcpu);
 			return 0;
 		}
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

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

[Edgecombe, Rick P]

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.

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?

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

[Sean Christopherson]

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.
> 
> 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?

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.

Re: [PATCH v2 1/3] KVM: x86: Add a helper to prepare vcpu->run for a SHUTDOWN exit to userspace

[Binbin Wu]

On 9/30/2026 8:11 AM, Sean Christopherson wrote:
> Add kvm_prepare_shutdown_exit() to dedup the paths that exit to userspace
> with KVM_EXIT_SHUTDOWN, all of which happen to be x86 (presumably other
> architectures use KVM_EXIT_SYSTEM_EVENT?).
> 
> Note, this adds a clearing of mmio_needed for SVM's shutdown_interception().
> Not clearing mmio_needed in that case is all but guaranteed to be benign;
> KVM should never enter the guest with outstanding emulated MMIO operations
> (the equivalent VMX and TDX paths likely copy+pasted the code from
> KVM_REQ_TRIPLE_FAULT, which does need to clear mmio_needed as KVM can
> synthesize a triple fault shutdown in the middle of instruction emulation).
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>

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

[Binbin Wu]

On 9/30/2026 8:11 AM, 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>

Reviewed-by: Binbin Wu <binbin.wu@linux.intel.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);
> +			return 0;
>  		}
>  		/*
>  		 * Always treat SEPT violations as write faults.  Ignore the

Re: [PATCH v2 3/3] KVM: TDX: Ratelimit the "EPT Violation on pending acceptance page" warning

[Binbin Wu]

On 9/30/2026 8:11 AM, Sean Christopherson wrote:
> Ratelimit TDX's kernel logging when a guest accesses an unaccepted page and
> has opted to disable EPT Violation #VEs for unaccepted accesses, as the
> pr_warn() is trivial for a misbehaving userspace to trigger.
> 
> Fixes: e6a85781f783 ("KVM: TDX: Detect unexpected SEPT violations due to pending SPTEs")
> Cc: stable@vger.kernel.org
> Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260923164348.2DB2D1F000FF@smtp.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Nit: should this patch be put before patch 2, to avoid a bisect window?

Otherwise,
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.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 e3723f1222fc..4cac43299851 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -1937,8 +1937,8 @@ static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu)
>  
>  	if (vt_is_tdx_private_gpa(vcpu->kvm, gpa)) {
>  		if (tdx_is_sept_violation_unexpected_pending(vcpu)) {
> -			pr_warn("Guest access before accepting 0x%llx on vCPU %d\n",
> -				gpa, vcpu->vcpu_id);
> +			pr_warn_ratelimited("Guest access before accepting 0x%llx on vCPU %d\n",
> +					    gpa, vcpu->vcpu_id);
>  			kvm_prepare_shutdown_exit(vcpu);
>  			return 0;
>  		}