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

[Artem Bityutskiy]

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.

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.

Thanks, Artem.