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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Tue, 2026-09-08 at 23:30 +0300, Artem Bityutskiy wrote:
> **Disclaimer**: I am new to KVM and TDX, still learning, let me know if
> some of my comments are off.
> 
> 
...
> 
> So maybe the way to go is to just follow 'msr_preservation.pdf' and
> adjust the allowlist? I find this approach safe and acceptable.

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.

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.


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.