All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	kvm@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	James Houghton <jthoughton@google.com>,
	Yan Zhao <yan.y.zhao@intel.com>,
	Binbin Wu <binbin.wu@linux.intel.com>,
	Ackerley Tng <ackerleytng@google.com>,
	Vishal Annapurve <vannapurve@google.com>
Subject: Re: [PATCH] KVM: TDX: Synthesize SHUTDOWN instead of returning -EIO on unhandled EPT violation
Date: Thu, 24 Sep 2026 09:39:08 +0800	[thread overview]
Message-ID: <50ccc54c-6cbb-4ae2-a84a-4dcbc958f91c@intel.com> (raw)
In-Reply-To: <20260923163315.1580860-1-seanjc@google.com>

On 9/24/2026 12:33 AM, Sean Christopherson wrote:
> Synthesize a triple fault, i.e. 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.

But reboot isn't good, neither.

I still think a new specific exit reason[1] would be better, as I suggested before.

[1] https://lore.kernel.org/kvm/1b0ea352-c645-461b-9e19-5202791f8e2d@intel.com/

> 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.
> 
> 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>
> ---
> 
> Compile tested only.
> 
>  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 7173ef3fc398..eb82f739a7c0 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;
>  		}
>  		/*
>  		 * Always treat SEPT violations as write faults.  Ignore the
> 
> base-commit: 30b5175943e709911702d8a9364145e911f57e3f


  parent reply	other threads:[~2026-09-24  1:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 16:33 [PATCH] KVM: TDX: Synthesize SHUTDOWN instead of returning -EIO on unhandled EPT violation Sean Christopherson
2026-09-23 16:43 ` sashiko-bot
2026-09-23 17:13   ` Sean Christopherson
2026-09-23 23:29 ` Edgecombe, Rick P
2026-09-23 23:51   ` Sean Christopherson
2026-09-24  0:31     ` Edgecombe, Rick P
2026-09-24  1:39 ` Xiaoyao Li [this message]
2026-09-24 14:13   ` Sean Christopherson
2026-09-24 14:40     ` Xiaoyao Li
2026-09-24 16:03       ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50ccc54c-6cbb-4ae2-a84a-4dcbc958f91c@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=ackerleytng@google.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jthoughton@google.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=vannapurve@google.com \
    --cc=x86@kernel.org \
    --cc=yan.y.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.