On 29/8/24 22:07, Jason Gunthorpe wrote:

On Thu, Aug 29, 2024 at 02:57:34PM +1000, Alexey Kardashevskiy wrote:

quoted

quoted

quoted

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.

quoted

Given you already have an issue with iommu driver synchronization this

looks like it might be a poor choice anyhow..

quoted

quoted

I wonder if there is enough value to try keeping the TIO_DEV_* and 

TIO_TDI_*

quoted

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