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

[Sean Christopherson <seanjc@google.com>]

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().

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;

> in tdx_handle_exit().
> [1]
> https://lore.kernel.org/all/646f9595-459f-4224-b4e5-4ec2eecc0bc6@intel.com/
> > 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.

> I think there will be more problems when TDX can exit with the reasons that
> are currently swizzled from the TDVMCALL. e.g., when EPT_MISCONFIG can
> happen on private memory.