Re: [PATCH v3 0/4] KVM: TDX: Validate directly configurable CPUID bits

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 9/2/2026 9:13 PM, Edgecombe, Rick P wrote:
> On Wed, 2026-09-02 at 18:29 +0800, Xiaoyao Li wrote:
>> So the proposal is making TDX behave as if the relevant VMCS save/load 
>> controls (if any) are set around TDH.VP.ENTER.
>>
>> In fact, what matters for host vmm is just the VM_EXIT_LOAD_XXX control. 
>> So the proposal becomes "If there is VM_EXIT_LOAD_XXX control for a 
>> state, TDX needs to restore the host state after TDH.VP.ENTER. If no 
>> such contorl, TDX sets the state to INIT state after TDH.VP.ENTER".
>>
>> It's a fancy idea. And it provides a clear rule of how TDX handles 
>> states of a feature so that host VMM developers don't need to read the 
>> TDX module API to figure out what's the value of a state after TDH.VP.ENTER.
>>
>> It's helpful for host VMM developers, though I'm not sure on TDX module 
>> developers.
> 
> I don't think they have agreed to it yet (Binbin?), but I think it mostly works
> this way already. Why do you think it is a burden on TDX module developers?

Because it can bring confusion to TDX module developers. VM_EXIT_LOAD_XXX control
is used by SEAM VMCS to load states for TDX module execution context. And I think
for most features SEAM VMCS doesn't set it (I don't check it though).

SEAMCALL is kind of a VM exit, and SEAMRET is kind of a VM entry. To automatically
save and restore the host state, what TDX needs are VM_EXIT_SAVE_XXX, VM_ENTRY_LOAD_XXX,
and vmcs guest state for XXX.