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

[Artem Bityutskiy]

On Wed, 2026-09-09 at 16:48 +0800, Binbin Wu wrote:
> > VMX:
> >   VM entry = load guest state from guest-state area
> >   VM exit  = save guest state into guest-state area,
> >              load host state from host-state area
> > 
> > TDX:
> >   SEAMCALL = save host state into SEAM VMCS guest-state area,
> >              load module state from SEAM VMCS host-state area
> >   SEAMRET  = restore host state from SEAM VMCS guest-state area
> > 
> > I may be reading the SDM wrong, let me know.
> 
> That's my understanding too.

Good, thanks for confirming.

> > 
> > So there are differences, and I was hoping to:
> > - Be corrected if I misinterpret the SDM and how things work.
> > - Get comments on whether the proposal took this into account.
> > - Get comments on how this affects, or does not affect, the proposal.
> 
> For host state clobbering behavior, we cares about the values of the host (VMX
> root mode) after SEAMRET.
> 
> When there is a control/field for "load host state from host-state area", I
> think there are two cases: 
> - If there is the corresponding control/field for "load guest state from
>   guest-state area", the TDX module could leverage it.
> - If there is no such corresponding control/field for "load guest state from
>   guest-state area", the TDX module could do it in software way to mimic it.
> 
> So from the view of the VMM, it can have the aligned behavior on host state
> clobbering behavior.

Now I see what you mean: make msr_preservation.pdf follow the same rule
as the VMX host-state restore, and let the TDX module help where HW behaves
differently (call this SW restore vs HW restore via VMCS).

That sounds good to me.

My only doubt is whether it can be guaranteed in every case. A HW restore
happens after a SW restore.

E.g., IA32_DEBUGCTL - HW clears it on VM exit (SDM 30.5.1), so whatever
TDX module puts there on the exit path, will be overwritten. Not that this
is an issue today, just using this as an example.

But I'd guess there would be only few problematic cases (if any).

Then you wrote this:

<cite>
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.
</cite>

That one reads as obviously right to me. If VMX and TDX differed in how
IA32_FRED_RSP0 and IA32_PL0_SSP are handled, that would be a red flag.

Did you go through all the MSRs and check that the VMX and TDX behavior
matches today?

Thanks!