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

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

On 8/28/2026 11:19 AM, Binbin Wu wrote:
> On 8/28/2026 3:33 AM, Edgecombe, Rick P wrote:
>> On Thu, 2026-08-27 at 11:18 +0800, Binbin Wu wrote:

<snip>

>>> Expected host state clobbering behavior for TDX
>>> ===============================================
>>> We also want to call for discussions about the expected host state
>>> clobbering behavior for TDX here for future features.
>>>
>>> For a normal VMX guest, VM entry/exit behavior for a given piece of CPU
>>> state is architecturally defined: state is either switched by hardware via
>>> VMCS host/guest fields, or left as the guest value on VM exit and managed
>>> by KVM in software.
>>>
>>> For TDs, the host/guest transition goes through TDH.VP.ENTER, and what the
>>> TDX module does with a given piece of host state is defined by the TDX
>>> module ABI rather than by the x86 architecture.
>>>
>>> What we would like to align on is the expected baseline behavior of
>>> TDH.VP.ENTER for future features.  The proposal is to have TDX simply
>>> match VMX behavior, i.e. on return from TDH.VP.ENTER, state that VMX would
>>> restore from the VMCS host fields is restored, and state that VMX would
>>> leave as the guest value is clobbered.  That keeps a single model for VMM,
>>> and means enabling a new feature for TDs requires the same work flow as
>>> enabling it for VMX.
>>
>> 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.

> It probably needs some TDX specific handling, since the TDX module clobbers the
> MSRs (setting them to either their INIT values or some default values), whereas
> in the VMX case the guest values are left.
> 
>> Depending on how much of which category we have, it
>> could be better for the kernel to have either one.
>>
>> And if TDX always saved/restored all state across VP.ENTER, then we don't need
>> bit filtering? What are the problems then with exposing everything to userspace
>> as we currently do?

IMO, allowing userspace to expose/enable a new feature to a guest 
without KVM first evaluating it is always dangerous. It's not just about 
the state clobbering. We can know the implication for a new feature.

For example, a feature consumes global per-socket resources. Allowing 
guest to use the feature might slowdown the host.

Another example is a feature is used to catch bad behaviors, and in this 
case host would like to enforce the feature being forced on for the 
guest instead of allowing the guest to use (disable) the feature freely.