Re: [RFC] TDX module configurability of 0x80000008

[Sean Christopherson <seanjc@google.com>]

On Tue, May 07, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-05-07 at 22:22 +0800, Chao Gao wrote:
> > > 2. There was some concern that exposing non-zero bits in [23:16] could
> > > confuse existing TDs. Of course KVM doesn't support any TDs today, but if
> > > this feature comes after initial KVM support for TDX and KVM wants to set
> > > it by default, then it could be an issue.
> > 
> > Do you mean some TDs may assert that [23:16] are 0s? A future-proof design
> > won't have this assertion. And this case (i.e., some CPUID bits become non-
> > zero) happens on every new generation of CPUs and doesn't confuse existing
> > OSes. I don't understand why it would be a problem for TDs.
> 
> Intel defined these as reserved. AMD defined them for guest MAXPA. So, yes, OSs
> should be masking them. I'm not suggesting that any are not, but TDX module
> folks were concerned about this, and that then KVM would not be able to turn
> this on later without breaking them. So just circling back here to double check.

I'm with Chao, a kernel/firmware implementation that asserts some CPUID bits that
are currently reserved on _some_ CPUs are always zero deserves to be broken.