On 15/3/25 11:08, Dan Williams wrote:
Alexey Kardashevskiy wrote:
The TDI bind operation moves the TDI into "RUN" state which means that
TEE resources are now to be used as encrypted, or the device will
refuse to operate. This requires RMP setup for MMIO BARs which is done
in 2 steps:
- RMPUPDATE on the host to assign host's MMIO ranges to GPA (like RAM);
- validate the RMP entry which is done via TIO GUEST REQUEST GHCB message
(unlike RAM for which the VM could just call PVALIDATE) but TDI bind must
complete first to ensure the TDI is in the LOCKED state so the location
of MMIO is fixed.
The bind happens on the first TIO GUEST REQUEST from the guest.
At this point KVM does not have host TDI BDFn so it exits to QEMU which
calls VFIO-IOMMUFD to bind the TDI.
Now, RMPUPDATE need to be done, in some place on the way back to the guest.
Possible places are:
a) the VFIO-IOMMUFD bind handler (does not know GPAs);
b) QEMU (can mmapp MMIO and knows GPA);
Given the guest_memfd momentum to keep private memory unmapped from the
host side do you expect to align with the DMABUF effort [1] to teach KVM
about convertible MMIO where the expectation is that convertible MMIO
need never be mmapped on the host side?
Well, I need to do better than the horrendous "[RFC PATCH v2 15/22] KVM:
X86: Handle private MMIO as shared" and this one fits the purpose so
yes. Thanks,
[1]: http://lore.kernel.org/20250123160827.GS5556@xxxxxxxxxx
--
Alexey
