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.
