Re: [RFC] TDX module configurability of 0x80000008

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


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

[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