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

[Edgecombe, Rick P]

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.

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.

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.