On Tue, Feb 18, 2025 at 10:10:01PM +1100, Alexey Kardashevskiy wrote: > When a TDISP-capable device is passed through, it is configured as > a shared device to begin with. Later on when a VM probes the device, > detects its TDISP capability (reported via the PCIe ExtCap bit > called "TEE-IO"), performs the device attestation and transitions it > to a secure state when the device can run encrypted DMA and respond > to encrypted MMIO accesses. > > Since KVM is out of the TCB, secure enablement is done in the secure > firmware. The API requires PCI host/guest BDFns, a KVM id hence such > calls are routed via IOMMUFD, primarily because allowing secure DMA > is the major performance bottleneck and it is a function of IOMMU. I still have concern about the vdevice interface for bind. Bind put the device to LOCKED state, so is more of a device configuration rather than an iommu configuration. So seems more reasonable put the API in VFIO? > > Add TDI bind to do the initial binding of a passed through PCI > function to a VM. Add a forwarder for TIO GUEST REQUEST. These two > call into the TSM which forwards the calls to the PSP. > > Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxx> > --- > > Both enabling secure DMA (== "SDTE Write") and secure MMIO (== "MMIO > validate") are TIO GUEST REQUEST messages. These are encrypted and > the HV (==IOMMUFD or KVM or VFIO) cannot see them unless the guest > shares some via kvm_run::kvm_user_vmgexit (and then QEMU passes those > via ioctls). > > This RFC routes all TIO GUEST REQUESTs via IOMMUFD which arguably should > only do so only for "SDTE Write" and leave "MMIO validate" for VFIO. The fact is HV cannot see the guest requests, even I think HV never have to care about the guest requests. HV cares until bind, then no HV side MMIO & DMA access is possible, any operation/state after bind won't affect HV more. And HV could always unbind to rollback guest side thing. That said guest requests are nothing to do with any host side component, iommu or vfio. It is just the message posting between VM & firmware. I suppose KVM could directly do it by calling TSM driver API. Thanks, Yilun
