On 29/8/24 22:07, Jason Gunthorpe wrote:
On Thu, Aug 29, 2024 at 02:57:34PM +1000, Alexey Kardashevskiy wrote:
Is "extend the MAP_DMA uAPI to accept {gmemfd, offset}" enough for the VFIO
context, or there is more and I am missing it?
No, you need to have all the virtual PCI device creation stuff linked
to a VFIO cdev to prove you have rights to do things to the physical
device.
The VM-to-VFIOdevice binding is already in the KVM VFIO device, the rest is
the same old VFIO.
Frankly, I'd rather not add any more VFIO stuff to KVM. Today KVM has
no idea of a VFIO on most platforms.
> Given you already have an issue with iommu driver synchronization this
looks like it might be a poor choice anyhow..
>> I wonder if there is enough value to try keeping the TIO_DEV_* and
TIO_TDI_*
API together or having TIO_DEV_* in some PCI module and TIO_TDI_* in KVM is
a non-confusing way to proceed with this. Adding things to the PCI's sysfs
from more places bothers me more than this frankenmodule. Thanks,
I wouldn't mix them up, they are very different. Just because they are
RPCs to the same bit of FW doesn't really mean they should be together
in the same interfaces or ops structures.
Both DEV_* and TDI_* use the same SecureSPDM channel (on top of the
PF#0's PCIe DOE cap) for IDE_KM (for DEV_*) and TDISP (for TDI_*) so
there is some common ground. Thanks,
--
Alexey
