On Thu, Apr 25, 2024, Rick P Edgecombe wrote: > 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. Yep. > But userspace still has to handle it. It can, but I was under the impression > it didn't (maybe bad assumption). I'm pretty sure QEMU handles accesses to non-existent MMIO with PCI abort semantics, i.e. ignores writes and returns all FFs for reads. > > > 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. Because the whole point of TDX is to protect the guest from the bad, naughty host? > If we think the TDX module should do it, then maybe we should have KVM sanity > filter these out today in preparation. Nope. KVM isn't in the guest's TCB, TDX is. KVM's stance is that userspace is responsible for providing a sane vCPU model, because defining what is "sane" is extremely difficult unless the definition is super prescriptive, a la TDX. E.g. letting the host map something that TDX's spec says will cause #VE would create a novel attack surface.
