Linux Media Controller development
 help / color / mirror / Atom feed
From: Alex Williamson <alex@shazbot.org>
To: Matt Evans <matt@ozlabs.org>
Cc: "Leon Romanovsky" <leon@kernel.org>,
	"Jason Gunthorpe" <jgg@nvidia.com>,
	"Alex Mastro" <amastro@fb.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"Pranjal Shrivastava" <praan@google.com>,
	"Longfang Liu" <liulongfang@huawei.com>,
	"Mahmoud Adam" <mngyadam@amazon.de>,
	"David Matlack" <dmatlack@google.com>,
	"Björn Töpel" <bjorn@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Ankit Agrawal" <ankita@nvidia.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, linux-pci@vger.kernel.org, alex@shazbot.org
Subject: Re: [PATCH v8 8/9] vfio/pci: Support mmap() of a VFIO DMABUF
Date: Tue, 13 Oct 2026 17:13:47 -0600	[thread overview]
Message-ID: <20261013171347.54e856c7@shazbot.org> (raw)
In-Reply-To: <20261006193643.76330-9-matt@ozlabs.org>

On Tue,  6 Oct 2026 20:36:36 +0100
Matt Evans <matt@ozlabs.org> wrote:

> A VFIO DMABUF can export a subset of a BAR to userspace by fd; add
> support for mmap() of this fd.  This provides another route for a
> process to map BARs, in which the process can only map a specific
> subset of a BAR represented by the exported DMABUF.
> 
> mmap() support enables userspace drivers to safely delegate BAR
> sub-ranges to other processes by sharing a DMABUF fd, without having
> to share the (omnipotent) VFIO device fd with them.
> 
> Since the main VFIO BAR mmap() is now DMABUF-aware, the new mmap() reuses
> the existing vm_ops.
>
> The lifecycle of an exported DMABUF remains decoupled from that of the
> device fd it came from, i.e. the device fd could be closed with DMABUF
> VMAs present, meaning a fault on a VMA could happen concurrently with
> vfio_pci_dma_buf_cleanup().
> 
> To deal with this scenario, the fault handler now temporarily takes a
> VFIO device registration to ensure the vdev remains valid, and then
> vdev locks can be taken.

This sounds like potentially measurable overhead if something is
slamming the fault handler where huge-fault is not supported or active.
Have you considered a fast path for the internal dmabuf where the
lifecycle is constrained?

Hopefully we can get those selftests included to avoid regressions.

Overall, I'm not finding too much to pick on in this series, but it
also hasn't collected much in the way of reviews.  For a fundamental
change like this, I hope we can get more eyes on it.  Thanks,

Alex

  reply	other threads:[~2026-10-13 23:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 19:36 [PATCH v8 0/9] vfio/pci: Add mmap() for DMABUFs Matt Evans
2026-10-06 19:36 ` [PATCH v8 1/9] vfio/pci: Remove DMABUF export dependency on vdev->memory_lock Matt Evans
2026-10-13 23:14   ` Alex Williamson
2026-10-14 18:05     ` Matt Evans
2026-10-06 19:36 ` [PATCH v8 2/9] vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume Matt Evans
2026-10-06 19:36 ` [PATCH v8 3/9] dma-buf: Provide dma_buf_set_name() Matt Evans
2026-10-07  9:22   ` Christian König
2026-10-12  6:27   ` Leon Romanovsky
2026-10-06 19:36 ` [PATCH v8 4/9] vfio/pci: Add a helper to look up PFNs for DMABUFs Matt Evans
2026-10-13 23:14   ` Alex Williamson
2026-10-14 18:25     ` Matt Evans
2026-10-06 19:36 ` [PATCH v8 5/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Matt Evans
2026-10-06 19:36 ` [PATCH v8 6/9] vfio/pci: Convert BAR mmap() to use a DMABUF Matt Evans
2026-10-06 19:36 ` [PATCH v8 7/9] vfio/pci: Clean up BAR zap and revocation Matt Evans
2026-10-13 23:13   ` Alex Williamson
2026-10-14 18:07     ` Matt Evans
2026-10-06 19:36 ` [PATCH v8 8/9] vfio/pci: Support mmap() of a VFIO DMABUF Matt Evans
2026-10-13 23:13   ` Alex Williamson [this message]
2026-10-14 20:38     ` Matt Evans
2026-10-06 19:36 ` [PATCH v8 9/9] vfio/pci: Revoke a DMABUF on request from userspace Matt Evans
2026-10-13 23:13   ` Alex Williamson
2026-10-14 19:02     ` Matt Evans

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=20261013171347.54e856c7@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=linux-pci@vger.kernel.org \
    --cc=liulongfang@huawei.com \
    --cc=matt@ozlabs.org \
    --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