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

[Binbin Wu <binbin.wu@linux.intel.com>]

On 9/9/2026 7:20 PM, Artem Bityutskiy wrote:
> 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 SEAMRET is actually a VM Entry, I think these special cases are during VM Exit.
For a VM entry, the TDX module should be able to set whatever valid values for host. 

> 
> 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?

Not yet.
This topic is put in the cover letter for discussions.
And the patch series itself doesn't depend on conclusion of the discussions.

> 
> Thanks!