Re: [PATCH v3 0/4] KVM: TDX: Validate directly configurable CPUID bits
From: Xiaoyao Li
Date: Wed Sep 02 2026 - 06:52:52 EST
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.