On Thu, 2024-04-25 at 23:09 +0800, Xiaoyao Li wrote: > > The idea is that TDX module could add the capability to configure these bits > > as > > well, so that TDs could match normal VMs for cases where there is a desire > > for > > the guests MAXPA to be smaller than the hosts. The requirements would be, > > roughly: > > - The VMM specifies the 0x80000008.EAX[23:16] when creating a TD. > > - The TDX module does sanity checking. > > - The 0x80000008.EAX[23:16] field is used to communicate the max > > addressable > > GPA to the guest. It will be used by the guest firmware to make sure > > resources like PCI bars are mapped into the addressable GPA. > > - If the guest attempts to access memory beyond the max addressable GPA, > > then > > the TDX module generates EPT violation to the VMM. For the VMM, this case > > means that the guest attempted to access "invalid" (I/O) memory. > > - The VMM will be expected to terminate the TD guest. The VMM may send > > a notification, but the TDX module doesn't necessarily need to know how. > > This is not the same as how it works for normal (non-TDX) VMs. > > For normal VMs, when userspace configures a smaller one than what > hardware EPT/NPT supports, it doesn't cause any issue if guest accesses > GPA beyond [23:16] but within hardware EPT/NTP capability. > > It's more a hint to guest that KVM doesn't enforce the semantics of it. > However, for TDX case, you are proposing to make it a hard rule. If we limit ourselves to worrying about valid configurations, accessing a GPA beyond [23:16] is similar to accessing a GPA with no memslot. Like you say, [23:16] is a hint, so there is really no change from KVM's perspective. It behaves like normal based on the [7:0] MAXPA. What do you think should happen in the case a TD accesses a GPA with no memslot? KVM/QEMU don't have a lot of options to recover. So are the differences here just the existing differences between normal VMs and TDX?
