On Thu, 2024-04-25 at 09:59 -0700, Sean Christopherson wrote: > > If we limit ourselves to worrying about valid configurations, > > Define "valid configurations". I meant configurations with no memslots above guest max pa. If there are memslots in that region, I don't know. Maybe valid is the wrong word. > > > 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). > > > 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. Also, it adds complexity for cases where KVM maps GPAs above guest maxpa anyway. So maybe we want it to just handle 2? It might have some nuances still. Another question, should we just tie guest maxpa to GPAW? Either enforce they are the same, or expose 23:16 based on GPAW.
