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

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