Re: [PATCH v3 4/4] KVM: TDX: Enable Bus Lock VM exit

[Sean Christopherson <seanjc@google.com>]

On Fri, Aug 14, 2026, Xiaoyao Li wrote:
> On 8/13/2026 10:43 PM, Sean Christopherson wrote:
> > On Thu, Aug 13, 2026, Xiaoyao Li wrote:
> > > On 8/13/2026 6:58 AM, Edgecombe, Rick P wrote:

...

> > 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.
> 
> tdx_is_exit_reason_valid() doesn't work unless we update the vp_enter_ret to
> one that isn't one of the status code with valid Exit Reason. See below.

Correct.

> About the idea, isn't the purpose of setting the Exit Reason to a synthesized
> one is to avoid the undefined Exit Reason causing false-positives when it
> happens to match one of the existing ones?

Yes.  The nuance is that I'm against clobbering the *full* exit reason.  I am
not against setting exit_reason.basic to something like EXIT_REASON_INVALID_STATE.

> If we are going to use tdx_is_exit_reason_valid(), does it mean we can drop
> the synthesized Exit Reason entirely and check tdx_is_exit_reason_valid()
> everywhere when KVM is going to consume Exit Reason?  e.g., for this initial
> bus_lock_detected bit handling here. we can avoid it by below. (Which makes
> it different for VMX, and somehow prevents consolidating the code between VMX
> and TDX around the exit handlers that we plan to do after series)

I'd rather not, as it would make checking for tdx_is_exit_reason_valid() much
more load bearing.  I.e. I want to minimize the number of flows that *need* to
check tdx_is_exit_reason_valid(), and an easy way to help on that front is to
ensure that exit_reason[31:16] is accurate with respect to what to the last
(attempted) entry to the guest.

> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index b6c30c4c6b84..52360313dd82 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -2169,7 +2169,8 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t
> fastpath)
>         int ret = __tdx_handle_exit(vcpu, fastpath);
> 
>         /* Exit to user space when bus lock was detected */
> -       if (vmx_get_exit_reason(vcpu).bus_lock_detected) {
> +       if (tdx_is_exit_reason_valid(vcpu) &&
> +           vmx_get_exit_reason(vcpu).bus_lock_detected) {
>                 if (ret > 0) {
>                         vcpu->run->exit_reason = KVM_EXIT_X86_BUS_LOCK;
>                         ret = 0;
> 
> > 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))
> 
> No, this doesn't work.
> 
> The previous vp_enter_ret was TDX_SUCCESS with
> EXIT_REASON_EXTERNAL_INTERRUPT. KVM handled it and is going to re-enter the
> TD. But wait_for_sept_zap is set by other vCPU thread, KVM decides to return
> directly but the vp_entere_ret isn't updated.

Oh, right, it really is the same situation as emulation_required, sort of.  The
key difference is that wait_for_sept_zap is per-VM, not per-VM, and so if it's
*cleared* between tdx_vcpu_run() and vt_handle_exit_irqoff(), then KVM would get
a false negative and again synthesize a duplicate IRQ.

Actually, can't we just do this?  Logically it's sound: if the exit was handled,
then there's nothing to be done.

diff --git arch/x86/kvm/x86.c arch/x86/kvm/x86.c
index 0626e835e9eb..6cace57e45fd 100644
--- arch/x86/kvm/x86.c
+++ arch/x86/kvm/x86.c
@@ -8374,7 +8374,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
        if (vcpu->arch.xfd_no_write_intercept)
                fpu_sync_guest_vmexit_xfd_state();
 
-       kvm_x86_call(handle_exit_irqoff)(vcpu);
+       if (exit_fastpath != EXIT_FASTPATH_EXIT_HANDLED)
+               kvm_x86_call(handle_exit_irqoff)(vcpu);
 
        if (vcpu->arch.guest_fpu.xfd_err)
                wrmsrq(MSR_IA32_XFD_ERR, 0);