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

On Tue, Aug 18, 2026, Xiaoyao Li wrote:
> 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.

I would rather do:

	vt->exit_reason.full = 0;
	vt->exit_reason.basic = ???;

So that it's abundantly clear that bits 31:16 hold *valid* state, i.e. to make it
more obvious that the value shoved into the basic exit reason is arbitrary, whereas
clearing bits 31:16 is not.