On Thu, Apr 25, 2024, Rick P Edgecombe wrote: > On Thu, 2024-04-25 at 09:59 -0700, Sean Christopherson wrote: > > > accessing a GPA beyond [23:16] is similar to accessing a GPA with no > > > memslot. > > > > No, it's not. A GPA without a memslot has *very* well-defined semantics in > > KVM, and KVM can provide those semantics for all guest-legal GPAs > > regardless of hardware EPT/NPT support. > > Sorry, not following. Are we expecting there to be memslots above the guest > maxpa 23:16? If there are no memslots in that region, it seems exactly like > accessing a GPA with no memslots. What is the difference between before and > after the introduction of guest MAXPA? (there will be normal VMs and TDX > differences of course). If there are no memslots, nothing from a functional perspectives, just a very slight increase in latency. Pre-TDX, KVM can always emulate in reponse to an EPT violation on an unmappable GPA. I.e. as long as there is no memslot, KVM doesn't *need* to create SPTEs, and so whether or not a GPA is mappable is completely irrelevant. Enter TDX, and suddenly that doesn't work because KVM can't emulate without guest cooperation. And to get guest cooperation, _something_ needs to kick the guest with a #VE. > > > 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? > > > > Synthesize a #VE into the guest. The GPA isn't a violation of the "real" > > MAXPHYADDR, so killing the guest isn't warranted. And that also means the > > VMM could legitimately want to put emulated MMIO above the max addressable > > GPA. Synthesizing a #VE is also aligned with KVM's non-memslot behavior > > for TDX (configured to trigger #VE). > > > > And most importantly, as you note above, the VMM *can't* resolve the > > problem. On the other hand, the guest *might* be able to resolve the > > issue, e.g. it could request MMIO, which may or may not succeed. Even if > > the guest panics, that's far better than it being terminated by the host as > > it gives the guest a chance to capture what led to the panic/crash. > > > > The only downside is that the VMM doesn't have a chance to "bless" the #VE, > > but since the VMM literally cannot handle the "bad" access in any other > > than killing the guest, I don't see that as a major problem. > > Ok, so we want the TDX module to expect the TD to continue to live. Then we need > to handle two things: > 1. Trigger #VE for a GPA that is mappable by the EPT level (we can already do > this) > 2. Trigger #VE for a GPA that is not mappable by the EPT level > > We could ask the TDX module to just handle both of these cases. But this means > KVM loses a bit of control and debug-ability from the host side. Why would the TDX module touch #1? Just leave it as is. > Also, it adds complexity for cases where KVM maps GPAs above guest maxpa > anyway. That should be disallowed. If KVM tries to map an address that it told the guest was impossible to map, then the TDX module should throw an error. > So maybe we want it to just handle 2? It might have some nuances still. I'm sure there are nuances, but I don't know that we care. I see three options: 1. Resume the guest without doing anything and hang the guest. 2. Punt the issue to the VMM and kill the guest. 3. Inject #VE into the guest and maybe the guest lives. #1 is terrible for obvious reasons, so given the choice between guaranteed death and a slim chance of survival, I'll take that slim chance of survival :-) > Another question, should we just tie guest maxpa to GPAW? Yes > Either enforce they are the same, or expose 23:16 based on GPAW. I can't think of any reason not to derive 23:16 from GPAW, unless I'm missing some subtlety, they're quite literally the same thing.
