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

[Sean Christopherson <seanjc@google.com>]

On Wed, Sep 23, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kvm: tdx: host log spam via repeated KVM_RUN on unhandled EPT violation
> --
> 
> commit 8eacf1c465f7e8b6cb99f1f4dae3c4af3bcde33c
> Author: Sean Christopherson <seanjc@google.com>
> 
> KVM: TDX: Synthesize SHUTDOWN instead of returning -EIO on unhandled EPT violation
> 
> This commit synthesizes a triple fault instead of returning -EIO when KVM
> encounters an EPT Violation from a guest accessing a pending page. This gives
> userspace the option to keep the VM alive or reboot it, rather than treating
> the situation as a fatal KVM bug.
> 
> > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> > index 7173ef3fc398e..eb82f739a7c04 100644
> > --- a/arch/x86/kvm/vmx/tdx.c
> > +++ b/arch/x86/kvm/vmx/tdx.c
> [ ... ]
> > @@ -1938,8 +1938,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_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
> > +			return 1;
> 
> [Severity: High]
> Will this change allow a malicious or buggy userspace VMM to flood the host
> kernel log?

Well, a malicious VMM could already spam the logs, e.g. by creating a new VM or
or spinning up a huge number of VMs.  I.e. this is a pre-existing issue.  But I
agree that it should be ratelimited (or maybe converted to vcpu_debug_ratelimited()?).

> By replacing kvm_vm_dead() with KVM_REQ_TRIPLE_FAULT and returning 1, KVM
> will clear the request during vcpu_enter_guest() and exit to userspace with
> KVM_EXIT_SHUTDOWN. If the VMM ignores this exit and repeatedly calls KVM_RUN
> without resetting the vCPU, KVM will immediately re-enter the guest.
> 
> The guest will hit the exact same unexpected SEPT violation in
> tdx_handle_ept_violation(), triggering this unconditional pr_warn() again.
> This can create an infinite loop that spams dmesg.
> 
> >  		}
> >  		/*
> >  		 * Always treat SEPT violations as write faults.  Ignore the
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260923163315.1580860-1-seanjc@google.com?part=1