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

[Sean Christopherson <seanjc@google.com>]

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.