On Wed, Aug 17, 2022 at 01:11:38PM -0300, Jason Gunthorpe wrote: > dma-buf has become a way to safely acquire a handle to non-struct page > memory that can still have lifetime controlled by the exporter. Notably > RDMA can now import dma-buf FDs and build them into MRs which allows for > PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory > from PCI device BARs. > > This series supports a use case for SPDK where a NVMe device will be owned > by SPDK through VFIO but interacting with a RDMA device. The RDMA device > may directly access the NVMe CMB or directly manipulate the NVMe device's > doorbell using PCI P2P. > > However, as a general mechanism, it can support many other scenarios with > VFIO. I imagine this dmabuf approach to be usable by iommufd as well for > generic and safe P2P mappings. > > This series goes after the "Break up ioctl dispatch functions to one > function per ioctl" series. > > This is on github: https://github.com/jgunthorpe/linux/commits/vfio_dma_buf > > Jason Gunthorpe (4): > dma-buf: Add dma_buf_try_get() > vfio: Add vfio_device_get() > vfio_pci: Do not open code pci_try_reset_function() > vfio/pci: Allow MMIO regions to be exported through dma-buf > > drivers/vfio/pci/Makefile | 1 + > drivers/vfio/pci/vfio_pci_config.c | 22 ++- > drivers/vfio/pci/vfio_pci_core.c | 33 +++- > drivers/vfio/pci/vfio_pci_dma_buf.c | 265 ++++++++++++++++++++++++++++ I forget about this.. Alex, do you want to start doing as Linus discused and I will rename this new file to "dma_buf.c" ? Or keep this directory as having the vfio_pci_* prefix for consistency? Jason
