From: Alex Williamson <alex@shazbot.org>
To: Matt Evans <mattev@meta.com>
Cc: "Leon Romanovsky" <leon@kernel.org>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Alex Mastro" <amastro@fb.com>,
"Christian König" <christian.koenig@amd.com>,
"Mahmoud Adam" <mngyadam@amazon.de>,
"David Matlack" <dmatlack@google.com>,
"Björn Töpel" <bjorn@kernel.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Kevin Tian" <kevin.tian@intel.com>,
"Ankit Agrawal" <ankita@nvidia.com>,
"Pranjal Shrivastava" <praan@google.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, alex@shazbot.org
Subject: Re: [PATCH 4/9] vfio/pci: Convert BAR mmap() to use a DMABUF
Date: Fri, 1 May 2026 16:19:15 -0600 [thread overview]
Message-ID: <20260501161915.75525c15@shazbot.org> (raw)
In-Reply-To: <20260416131815.2729131-5-mattev@meta.com>
On Thu, 16 Apr 2026 06:17:47 -0700
Matt Evans <mattev@meta.com> wrote:
> Convert the VFIO device fd fops->mmap to create a DMABUF representing
> the BAR mapping, and make the VMA fault handler look up PFNs from the
> corresponding DMABUF. This supports future code mmap()ing BAR
> DMABUFs, and iommufd work to support Type1 P2P.
>
> First, vfio_pci_core_mmap() uses the new
> vfio_pci_core_mmap_prep_dmabuf() helper to export a DMABUF
> representing a single BAR range. Then, the vfio_pci_mmap_huge_fault()
> callback is updated to understand revoked buffers, and uses the new
> vfio_pci_dma_buf_find_pfn() helper to determine the PFN for a given
> fault address.
>
> Now that the VFIO DMABUFs can be mmap()ed, vfio_pci_dma_buf_move() and
> vfio_pci_dma_buf_cleanup() need to zap PTEs on revocation and cleanup
> paths.
>
> CONFIG_VFIO_PCI_CORE now unconditionally depends on
> CONFIG_DMA_SHARED_BUFFER. CONFIG_VFIO_PCI_DMABUF remains, to
> conditionally include support for VFIO_DEVICE_FEATURE_DMA_BUF, and
> depends on CONFIG_PCI_P2PDMA.
>
> Signed-off-by: Matt Evans <mattev@meta.com>
> ---
> drivers/vfio/pci/Kconfig | 3 +-
> drivers/vfio/pci/Makefile | 3 +-
> drivers/vfio/pci/vfio_pci_core.c | 86 ++++++++++++++++++------------
> drivers/vfio/pci/vfio_pci_dmabuf.c | 14 +++++
> drivers/vfio/pci/vfio_pci_priv.h | 11 +---
> 5 files changed, 71 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
> index 296bf01e185e..2074f2a941e1 100644
> --- a/drivers/vfio/pci/Kconfig
> +++ b/drivers/vfio/pci/Kconfig
> @@ -6,6 +6,7 @@ config VFIO_PCI_CORE
> tristate
> select VFIO_VIRQFD
> select IRQ_BYPASS_MANAGER
> + select DMA_SHARED_BUFFER
>
> config VFIO_PCI_INTX
> def_bool y if !S390
> @@ -56,7 +57,7 @@ config VFIO_PCI_ZDEV_KVM
> To enable s390x KVM vfio-pci extensions, say Y.
>
> config VFIO_PCI_DMABUF
> - def_bool y if VFIO_PCI_CORE && PCI_P2PDMA && DMA_SHARED_BUFFER
> + def_bool y if PCI_P2PDMA
But here we introduce the call chain:
vfio_pci_core_mmap()
-> vfio_pci_core_mmap_prep_dmabuf()
-> pcim_p2pdma_provider()
Where pcim_p2pdma_provider() requires PCI_P2PDMA. So honestly,
VFIO_PCI_CORE depends on PCI_P2PDMA. I think that's a pretty
significant regression.
Exporting dma-bufs from vfio-pci is a feature, but mmap of MMIO BARs is
a legacy requirement. That legacy requirement now depends on
PCI_P2PDMA, which depends on 64BIT and ZONE_DEVICE.
It's possible that our 32-bit support is already broken and we can
easily codify it in Kconfig. We should check. Otherwise it seems
pretty harsh to drop it without notice, or make it fundamentally broken
by exposing mmap support flags for regions where mmap is no longer
available.
ZONE_DEVICE is harder, it seems like it's possible there could be
minimal 64-bit custom kernel configs where vfio-pci currently works
without ZONE_DEVICE.
We might be headed to this impasse already as dma-buf is required to
have feature-complete compatibility with iommufd, but I had hoped we'd
be able to manage that with full legacy functionality through the
transition. Thanks,
Alex
next prev parent reply other threads:[~2026-05-01 22:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 13:17 [PATCH 0/9] vfio/pci: Add mmap() for DMABUFs Matt Evans
2026-04-16 13:17 ` [PATCH 1/9] vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put Matt Evans
2026-04-24 18:05 ` Jason Gunthorpe
2026-05-01 19:12 ` Alex Williamson
2026-04-16 13:17 ` [PATCH 2/9] vfio/pci: Add a helper to look up PFNs for DMABUFs Matt Evans
2026-04-24 18:15 ` Jason Gunthorpe
2026-04-16 13:17 ` [PATCH 3/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Matt Evans
2026-04-24 18:24 ` Jason Gunthorpe
2026-04-30 16:47 ` Matt Evans
2026-04-30 17:11 ` Jason Gunthorpe
2026-04-16 13:17 ` [PATCH 4/9] vfio/pci: Convert BAR mmap() to use a DMABUF Matt Evans
2026-05-01 22:19 ` Alex Williamson [this message]
2026-05-04 7:40 ` Jason Gunthorpe
2026-04-16 13:17 ` [PATCH 5/9] vfio/pci: Provide a user-facing name for BAR mappings Matt Evans
2026-04-24 18:26 ` Jason Gunthorpe
2026-05-01 22:44 ` Alex Williamson
2026-04-16 13:17 ` [PATCH 6/9] vfio/pci: Clean up BAR zap and revocation Matt Evans
2026-05-01 23:19 ` Alex Williamson
2026-04-16 13:17 ` [PATCH 7/9] vfio/pci: Support mmap() of a VFIO DMABUF Matt Evans
2026-04-24 18:30 ` Jason Gunthorpe
2026-04-16 13:17 ` [PATCH 8/9] vfio/pci: Permanently revoke a DMABUF on request Matt Evans
2026-04-16 13:17 ` [PATCH 9/9] vfio/pci: Add mmap() attributes to DMABUF feature Matt Evans
2026-04-24 18:31 ` Jason Gunthorpe
2026-04-26 10:52 ` Leon Romanovsky
2026-04-27 14:36 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260501161915.75525c15@shazbot.org \
--to=alex@shazbot.org \
--cc=amastro@fb.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=bjorn@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dmatlack@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mattev@meta.com \
--cc=mngyadam@amazon.de \
--cc=praan@google.com \
--cc=sumit.semwal@linaro.org \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox