Re: [RFC] TDX module configurability of 0x80000008

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 4/25/2024 12:55 AM, Edgecombe, Rick P wrote:

This is a new effort to solicit community feedback for potential future TDX
module features. There are two features in different stages of development
around the configurability of the max physical address exposed in
0x80000008.EAX. I was hoping to get some comments on them and share the current
plans on whether to implement them in KVM.

One of the TDX module features is called MAXPA_VIRT. In short, it is similar to
KVM’s allow_smaller_maxphyaddr. It requires an explicit opt-in by the VMM, and
allows a TD’s 0x80000008.EAX[7:0] to be configured by the VMM. Accesses to
physical addresses above the specified value by the TD will cause the TDX module
to inject a mostly correct #PF with the RSVD error code set. It has to deal with
the same problems as allow_smaller_maxphyaddr for correctly setting the RSVD
bit. I wasn’t thinking to push this feature for KVM due the movement away from
allow_smaller_maxphyaddr and towards 0x80000008.EAX[23:16].

There is also a potential future TDX module feature currently being evaluated
around the configurability of 0x80000008.EAX[23:16]. I wanted to get some
community comments on the feature while it is still in the early stages of

0x80000008[7:0] is defined by the SDM as MAXPHYADDR. KVM is designed to work
with guest MAXPHYADDR set to host MAXPHYADDR. In the future there is work for
KVM to also accommodate a potentially smaller value in 0x80000008.EAX[23:16] for
normal VMs. This value is defined by AMD spec as GuestPhysAddrSize:
    Maximum guest physical address size in bits. This number applies only to guests
    using nested paging. When this field is zero, refer to the PhysAddrSize field
    for the maximum guest physical address size.

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,
  - 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.

Glad to hear any comments. Thanks.


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux