The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	 "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"kas@kernel.org" <kas@kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "nik.borisov@suse.com" <nik.borisov@suse.com>
Subject: Re: [PATCH v3 4/4] KVM: TDX: Enable Bus Lock VM exit
Date: Thu, 13 Aug 2026 07:43:34 -0700	[thread overview]
Message-ID: <an3YFiDbjRs3PUwn@google.com> (raw)
In-Reply-To: <1cf47118-2a19-44d5-ab74-b4c7ffa8890c@intel.com>

On Thu, Aug 13, 2026, Xiaoyao Li wrote:
> On 8/13/2026 6:58 AM, Edgecombe, Rick P wrote:
> > On Wed, 2026-08-12 at 16:02 +0800, Xiaoyao Li wrote:
> > > -	if (unlikely(READ_ONCE(to_kvm_tdx(vcpu->kvm)->wait_for_sept_zap)))
> > > +	if (unlikely(READ_ONCE(to_kvm_tdx(vcpu->kvm)->wait_for_sept_zap))) {
> > > +		vt->exit_reason.bus_lock_detected = 0;
> > >   		return EXIT_FASTPATH_EXIT_HANDLED;
> > > +	}
> > 
> > This still feels hacky to me. It at least deserves a comment I think. If you
> > spin another version.
> 
> I spent more time on this today and I find there is an existing issue. When
> the previous Exit Reason is EXIT_REASON_EXTERNAL_INTERRUPT, the early return
> here can go to the path due to the stale exit_reason.
> 
> kvm_x86_call(handle_exit_irqoff)(vcpu)
>   vmx_handle_exit_irqoff()
>     handle_external_interrupt_irqoff()
> 
> This makes the host process the external interrupt twice, and maybe more
> times if the wait_for_sept_zap remains longer.
> 
> I think we need an separate fix to set
> 
> 	vt->exit_reasons.full = TDX_INVALID_EXIT_REASON;
> 
> so that if some patch is going to consume the stale Exit Reason, it can be
> caught by TDX_INVALID_EXIT_REASON.

The more I look at this, the more I'm against shoving garbage into vt->exit_reasons.
With tdx_is_exit_reason_valid(), this is trivially easy to handle, *and* explicitly
captures the logic instead of subtly rerouting KVM away from meaningful handling.

diff --git a/arch/x86/kvm/vmx/main.c b/arch/x86/kvm/vmx/main.c
index 95d89d809c19..a1f5b5dc1fa3 100644
--- a/arch/x86/kvm/vmx/main.c
+++ b/arch/x86/kvm/vmx/main.c
@@ -157,6 +157,14 @@ static fastpath_t vt_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
        return vmx_vcpu_run(vcpu, run_flags);
 }
 
+static void vt_handle_exit_irqoff(struct kvm_vcpu *vcpu)
+{
+       if (is_td_vcpu(vcpu) && !tdx_is_exit_reason_valid(vcpu))
+               return;
+
+       vmx_handle_exit_irqoff();
+}
+
 static int vt_handle_exit(struct kvm_vcpu *vcpu,
                          enum exit_fastpath_completion fastpath)
 {
@@ -1071,7 +1079,7 @@ struct kvm_x86_ops vt_x86_ops __initdata = {
        .load_mmu_pgd = vt_op(load_mmu_pgd),
 
        .check_intercept = vmx_check_intercept,
-       .handle_exit_irqoff = vmx_handle_exit_irqoff,
+       .handle_exit_irqoff = vt_op(handle_exit_irqoff),
 
        .update_cpu_dirty_logging = vt_op(update_cpu_dirty_logging),

      reply	other threads:[~2026-08-13 14:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  8:02 [PATCH v3 0/4] KVM: TDX: Enable VM-DoS Prevention Features for TDX Xiaoyao Li
2026-08-12  8:02 ` [PATCH v3 1/4] KVM: TDX: Enable Notify VM exit Xiaoyao Li
2026-08-12  8:02 ` [PATCH v3 2/4] KVM: TDX: Set bits 31:16 to 0 for the synthesized Exit Reason Xiaoyao Li
2026-08-12 21:58   ` Edgecombe, Rick P
2026-08-12  8:02 ` [PATCH v3 3/4] KVM: TDX: Don't assume exit_reason[31:16] as all-0 in tdx_to_vmx_exit_reason() Xiaoyao Li
2026-08-12  8:02 ` [PATCH v3 4/4] KVM: TDX: Enable Bus Lock VM exit Xiaoyao Li
2026-08-12 22:58   ` Edgecombe, Rick P
2026-08-13 11:17     ` Xiaoyao Li
2026-08-13 14:43       ` Sean Christopherson [this message]

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=an3YFiDbjRs3PUwn@google.com \
    --to=seanjc@google.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=xiaoyao.li@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox