On Thu, 2024-04-25 at 14:39 -0700, Sean Christopherson wrote: > 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. Right, although there are gaps in emulation that could fail. If the emulation succeeds and there is an MMIO exit targeting a totally unknown GPA, then I guess it's up to userspace to decide what to do. KVM's done its job. But userspace still has to handle it. It can, but I was under the impression it didn't (maybe bad assumption). > > 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. I think it won't even come up if GPAW is locked to 23:16 like discussed below. (and the current plan for picking EPT level). > > > 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. Hmm. I'll mention this, but I don't see why KVM needs the TDX module to filter it. It seems in the range of userspace being allowed to create nonsense configurations that only hurt its own guest. If we think the TDX module should do it, then maybe we should have KVM sanity filter these out today in preparation. > > > 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 :-) Yes, maybe this proposal was being a bit lazy. > > > 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. So we have: - Expose GPAW in 23:16 - Inject #VE if ept violation is for gpa that can't be mapped by EPT level Seems relatively simple. I'll wait a bit for more comments, and circle back with TDX module folks.
