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? [1]: http://lore.kernel.org/20250123160827.GS5556@xxxxxxxxxx
