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

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:

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?

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.