Re: [PATCH v3 3/4] KVM: TDX: Don't assume exit_reason[31:16] as all-0 in tdx_to_vmx_exit_reason()

On Mon, Aug 17, 2026, Xiaoyao Li wrote:
> On 8/14/2026 11:12 PM, Sean Christopherson wrote:
> > On Fri, Aug 14, 2026, Xiaoyao Li wrote:
> > > On 8/14/2026 7:44 AM, Sean Christopherson wrote:
> > > > On Wed, Aug 12, 2026, Rick P Edgecombe wrote:
> > > > > Side note. I really dislike how tangled this area is for something that seems
> > > > > like it should be much more straightforward. Deriving partially I think from the
> > > > > overloading of the TDVMCALL leafs with the exit reasons. So we have things like:
> > > > > ...
> > > > > 	case EXIT_REASON_EPT_VIOLATION:
> > > > > 		return EXIT_REASON_EPT_MISCONFIG;
> > > > > ...
> > > > 
> > > > I peeked at that code again, and FWIW I still think swizzling the exit_reason for
> > > > TDVMCALL is the least awful solution.  If we don't do that, then we'll have to
> > > > update every single use of the exit_reason to demux TDVMCALL into the "real" exit
> > > > reason, which will be a mess.
> > > 
> > > I'm not sure if you read my idea[1]?
> > > 
> > > I think there is only one place KVM cares about the exit_reason TDVMCALL,
> > > just the
> > > 
> > > 	case EXIT_REASON_TDCALL:
> > 
> > No, the massaged exit_reason is also subtley consumed via trace_kvm_exit().
> 
> yeah. This is exactly the one I don't like, it looks like trace_kvm_exit()
> is tracing the wrong exit reason, though it is by intentional.
> 
> > It's also consumed by tdx_complete_emulated_msr():
> > 
> > 	if (vmx_get_exit_reason(vcpu).basic == EXIT_REASON_MSR_READ)
> > 
> > and by tdx_interrupt_allowed()
> > 
> > 	return vmx_get_exit_reason(vcpu).basic != EXIT_REASON_HLT ||
> > 	       !to_tdx(vcpu)->vp_enter_args.r12;
> > 
> > and by tdx_protected_apic_has_interrupt():
> > 
> > 	if (vmx_get_exit_reason(vcpu).basic != EXIT_REASON_HLT ||
> > 	    to_tdx(vcpu)->vp_enter_args.r12)
> > 		return false;
> 
> Ah, I really should have checked the code more carefully.
> 
> > > in tdx_handle_exit().
> > > [1]
> > > https://lore.kernel.org/all/[email protected]/
> > > > And once we track the exit_reason separately from vp_enter_ret, IMO it all becomes
> > > > more logical and easier to follow.  vp_enter_ret holds the information about why
> > > > VP.ENTER returned/exited, while exit_reason holds information about why the _guest_
> > > > exited.  Obviously it's imperfect since we're still fudging EXIT_REASON_EPT_MISCONFIG,
> > > > but again, I think that's a better alternative than demuxing exit_reason in multiple
> > > > locations.
> > > 
> > > The question do we really need to swizzle EXIT_REASON_TDCALL to other exit
> > > reasons ahead? why cannot them just be handled in the central handler for
> > > EXIT_REASON_TDCALL?
> > 
> > Because as above, it's not as central as you think.  If we want to not swizzle
> > the exit_reason, then IMO the only sane way to do that is to not track exit_reason
> > for TDX vCPUs, i.e. move vcpu_vt.exit_reason back to vcpu_vmx and force TDX to
> > always demux vp_enter_ret every time.
> 
> How about adding a specific field to track the TDVMCALL leaf? Full diff as
> below (the EPT MISCONFIG part can be split into a separate one)

I like it even less than demuxing vp_enter_ret on demand.  It has all the same
flaws as demuxing vp_enter_ret, because it's effectively just a cache of the
result of demuxing vp_enter_ret.  And caching values on entry/exit boundaries
adds additional risk;  I can point you at a number of bugs in the past where KVM
consumed stale data, e.g. because some chunk of code got moved to run before a
cached field was refreshed.  That's unlikekly to be a problem here, but anytime
data is cached it introduces risk of consuming stale data.

And the cost of demuxing vp_enter_ret every time doesn't concern me, at all.
What I don't like is relying on call sites to know that the exit_reason needs to
be demuxed in the first place, because that will be brittle and error prone.
That's why I'd be ok if vcpu_vt.exit_reason simply didn't exist: it becomes
impossible to check the wrong exit field because there's only one such field.

I'm ok caching the fully processed vcpu_vt.exit_reason, i.e. with the code now,
because only the TDVMCALL path needs to be aware that it may have undergone
processing, *and* KVM can WARN if that processing didn't happen as expected.

Whereas checking the "right" exit reason requires doing so in multiple paths and
doesn't have a natural sanity check.