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

[Xiaoyao Li]

On 8/18/2026 2:06 AM, Sean Christopherson wrote:
> On Sat, Aug 15, 2026, Xiaoyao Li wrote:
> > On 8/14/2026 11:46 PM, Sean Christopherson wrote:
> > > 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.
> >
> > I'm not sure why you are not OK with setting the bit[31:16] to 0 ...
>
> I'm all for that.  I'm against setting them to 1, which is what using -1u does.
>
> Ah, I'm guessing my use of "clobbering" is confusing.  I was mentally viewing
> setting them to '1' as clobbering, versus setting them to '0' as "doing the right
> thing.
>
> E.g. the VM-Exit (that didn't happen) wasn't due to a failed guest consistency
> check; it certainly wasn't an SMI from VMX Root, nor was an MTF pending at the
> time of the SMI that didn't happen; the guest wasn't in enclave mode; there was
> no concident bus lock; all other bits are reserved to zero.
>
> Sorry, I should have clarified that writing the full exit reason is ok, but setting
> arbitrary bits in a way that isn't consistent with reality is not.

I will add a separate patch in the next version to set

  vt->exit_reasons.full = TDX_INVALID_EXIT_REASON;

where TDX_INVALID_EXIT_REASON is U16_MAX, i.e. 0x0000FFFF.


For change of below, will be in another series

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);