Re: [RFC] TDX module configurability of 0x80000008

[Sean Christopherson <seanjc@google.com>]

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.