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

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

On 9/2/2026 1:41 AM, Edgecombe, Rick P wrote:
> On Tue, 2026-09-01 at 17:38 +0800, Xiaoyao Li wrote:
>>>> Ideally the TDX save/restore would share code with normal VMs. On the
>>>> other hand if we don't share enter/exit paths sufficiently, we may need to
>>>> duplicate some save/restore in tdx code.
>>
>> (Copy the FRED example here for reference)
>>
>>   >>>
>>   >>> FRED is a useful concrete example.  Under VMX, the FRED host state in
>>   >>> IA32_FRED_CONFIG, IA32_FRED_STKLVLS, IA32_FRED_RSP1-3 and
>>   >>> IA32_FRED_SSP1-3 is covered by the VMCS host-state area, so the TDX
>> module
>>   >>> is expected to restore these MSRs on TDH.VP.ENTER return.
>> IA32_FRED_RSP0
>>   >>> and IA32_PL0_SSP (a.k.a. IA32_FRED_SSP0) are handled by software,
>> so the
>>   >>> TDX module is expected to clobber them on TDH.VP.ENTER return.
>>
>> What I get, is not matching VMX behavior but matching the behavior KVM
>> will perform for VMX. They are based on the assumption that KVM will
>> always enable the save/restore VMCS fields for a new feature. But I
>> don't think we can guarantee it.
>>
>> To me, "have TDX simply match VMX behavior" means:
>>
>> 1. if the VMX unconditionally save/restore a state, then TDX will do so.
>>
>> 2. if there are vm-entry/vm-exit load/save VMCS fields for a state, then
>> provide the equivalent per-TD configurable interfaces which matches the
>> VMCS fields.
> 
> What do you mean by this? Expose a TDX module interface to configure the clobber
> behavior for each feature with load/save configuration? That was similar to what
> we originally discussed, before pivoting to this solution.

yeah. This is what I meant. I was trying to show my literal 
understanding on "The proposal is to have TDX simply match VMX 
behavior". i.e., I don't think "have TDX simply match VMX behavior" is a 
good name/summary for what Binbin has proposed.

> I was thinking if you configured a feature (for example shadow stack), it would
> automatically set the VMCS save/restore settings associated with that feature.
> (VM_EXIT_LOAD_CET_STATE/VM_ENTRY_LOAD_CET_STATE)
> 
> This won't necessarily match KVM's behavior, because it could decide to not use
> the features. But we can probably get close with a simple rule that can make
> sense for all the VMMs.

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.

> If later we want a host clobber interface on top of the bit filtering, in order
> to minimize TDX special handling, we can probably add it later for features we
> care about. I'd think we don't need it right now.