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

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

On 9/9/2026 2:52 PM, Artem Bityutskiy wrote:
> On Tue, 2026-09-08 at 22:31 +0000, Edgecombe, Rick P wrote:
>> We are kind of discussing what recommendations we should give about how
>> msr_preservation.pdf should be defined for new CPUID bit based features. So
>> saying to follow msr_preservation.pdf is self referential.
> 
> OK, thanks for elaborating. The e-mail was vague about that.
> 
>> Again, please do not treat the TDX specs as something to be handed down and
>> "followed". I think this is something to get used to for TDX. I mean, upstream
>> never wants to adapt to platform arch that fits awkwardly, but it's even tougher
>> to swallow when the arch is mostly SW defined. And further, the people working
>> on the TDX arch want to hear such requirements from upstream.
> 
> Agreed, that matches my understanding. Reminders are useful in general,
> but this was not that case.
> 
>> Here, the thing to discuss is how TDX should define new features that will
>> clobber host state (e.g. bits that would appear in msr_preservation.pdf as not
>> being preserved).
>>
>> There have been several PUCK discussions on the problem this series is tackling,
>> and actually several attempts to solve the problem during the base series. More
>> recently a host clobbering control was proposed that attempted to make it safe,
>> but it was not accepted. That proposal brought up the topic of whether having
>> select states clobbered was actually an unproven optimization.
>>
>> Now that we are moving back to an allow list type solution, what guidance should
>> we give on this other surfaced topic. Since TDX shares some save/restore logic
>> with normal VMs, we should have it work well with that code. So forgetting about
>> the performance optimization question, how to have it work in a sensible way
>> with the shared code paths.
> 
> Rick,
> 
> In general, the TDX case and the VMX case behaving the same way is
> best. I thought that consistency is always obviously a good thing,
> but let me acknowledge it explicitly.
> 
> I was trying to dig deeper into the proposal and analyze it.
> 
> <cite>
> 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.
> </cite>
> 
> My point was that hardware behaves differently for VMX guests and for
> the VMM<->TDX. This is not about following "boss specs", it is what the
> SDM describes.
> 
> For VMX, the VMCS host-state area is loaded by hardware on VM exit
> (SDM 27.5). For SEAMCALL and SEAMRET, the SDM seems to say they operate
> like an SMM VM exit and a VM entry returning from SMM (SDM 35.1), and
> those save state into the guest-state area of the transfer VMCS
> (SDM 34.15.2.2).
> 
> 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.

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