On Tue, 30 Sep 2025 10:57:48 +0300 Leon Romanovsky leon@kernel.org wrote:
On Mon, Sep 29, 2025 at 03:17:40PM -0600, Alex Williamson wrote:
On Sun, 28 Sep 2025 17:50:17 +0300 Leon Romanovsky leon@kernel.org wrote:
From: Leon Romanovsky leonro@nvidia.com
Add new kernel config which indicates support for dma-buf export of MMIO regions, which implementation is provided in next patches.
Signed-off-by: Leon Romanovsky leonro@nvidia.com
drivers/vfio/pci/Kconfig | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig index 2b0172f54665..55ae888bf26a 100644 --- a/drivers/vfio/pci/Kconfig +++ b/drivers/vfio/pci/Kconfig @@ -55,6 +55,26 @@ config VFIO_PCI_ZDEV_KVM To enable s390x KVM vfio-pci extensions, say Y. +config VFIO_PCI_DMABUF
- bool "VFIO PCI extensions for DMA-BUF"
- depends on VFIO_PCI_CORE
- depends on PCI_P2PDMA && DMA_SHARED_BUFFER
- default y
- help
Enable support for VFIO PCI extensions that allow exportingdevice MMIO regions as DMA-BUFs for peer devices to access viapeer-to-peer (P2P) DMA.This feature enables a VFIO-managed PCI device to export a portionof its MMIO BAR as a DMA-BUF file descriptor, which can be passedto other userspace drivers or kernel subsystems capable ofinitiating DMA to that region.Say Y here if you want to enable VFIO DMABUF-based MMIO exportsupport for peer-to-peer DMA use cases.If unsure, say N.source "drivers/vfio/pci/mlx5/Kconfig" source "drivers/vfio/pci/hisilicon/Kconfig"
This is only necessary if we think there's a need to build a kernel with P2PDMA and VFIO_PCI, but not VFIO_PCI_DMABUF. Does that need really exist?
It is used to filter build of vfio_pci_dmabuf.c - drivers/vfio/pci/Makefile: vfio-pci-core-$(CONFIG_VFIO_PCI_DMABUF) += vfio_pci_dmabuf.o
Maybe my question of whether it needs to exist at all is too broad. Does it need to be a user visible Kconfig option? Where do we see the need to preclude this feature from vfio-pci if the dependencies are enabled?
I also find it unusual to create the Kconfig before adding the supporting code. Maybe this could be popped to the end or rolled into the last patch if we decided to keep it. Thanks,
It is leftover from previous version, I can squash it, but first we need to decide what to do with pcim_p2pdma_init() call, if it needs to be guarded or not.
As in the other thread, I think it would be cleaner in an IS_ENABLED branch. I'm tempted to suggest we filter out EOPNOTSUPP to allow it to be unconditional, but I understand your point with the list_head initialization. Thanks,
Alex