Re: [RFC] TDX module configurability of 0x80000008

[Chao Gao <chao.gao@intel.com>]

On Mon, May 06, 2024 at 06:40:03PM +0000, Edgecombe, Rick P wrote:
>Follow up on this:
>
>1. The plan is to just always inject the #VEs for private and shared GPAs that
>exceed GPAW. (i.e. not pass the subset of EPT violations that could be handled
>by the VMM by clearing suppress #VE)
>
>
>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.

>
>For normal VMs, is there any concern that guests might not be masking the bits
>correctly?
>
>TDX module folks were pushing for a guest opt-in out of concern some breakages
>could result. Of course it requires additional enabling in the guest OS and
>vBIOS then. I was thinking it should be a host opt-in without guest control. If
>there was a problem it could be a host userspace opt-in. Any concerns there?
>
>Thanks,
>
>Rick