On Wed, Jun 10, 2026 at 04:43:18PM +0100, Matt Evans 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()
> zaps PTEs (used on the revocation and cleanup paths).
>
> CONFIG_VFIO_PCI_CORE now unconditionally depends on
> CONFIG_DMA_SHARED_BUFFER and CONFIG_PCI_P2PDMA_CORE. The
> CONFIG_VFIO_PCI_DMABUF feature conditionally includes support for
> VFIO_DEVICE_FEATURE_DMA_BUF, depending on the availability of
> CONFIG_PCI_P2PDMA.
>
> Signed-off-by: Matt Evans <matt(a)ozlabs.org>
> ---
> drivers/vfio/pci/Kconfig | 5 +-
> drivers/vfio/pci/Makefile | 3 +-
> drivers/vfio/pci/vfio_pci_core.c | 75 +++++++++++++++++++-----------
> drivers/vfio/pci/vfio_pci_dmabuf.c | 12 +++++
> drivers/vfio/pci/vfio_pci_priv.h | 11 +----
> 5 files changed, 67 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
> index 296bf01e185e..67a2ae1fbc04 100644
> --- a/drivers/vfio/pci/Kconfig
> +++ b/drivers/vfio/pci/Kconfig
> @@ -6,6 +6,8 @@ config VFIO_PCI_CORE
> tristate
> select VFIO_VIRQFD
> select IRQ_BYPASS_MANAGER
> + select PCI_P2PDMA_CORE
> + select DMA_SHARED_BUFFER
>
> config VFIO_PCI_INTX
> def_bool y if !S390
> @@ -56,7 +58,8 @@ 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
> + depends on VFIO_PCI_CORE
>
> source "drivers/vfio/pci/mlx5/Kconfig"
>
[...]
> int vfio_pci_core_mmap_prep_dmabuf(struct vfio_pci_core_device *vdev,
> struct vm_area_struct *vma,
> @@ -532,6 +538,10 @@ void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
> struct vfio_pci_dma_buf *tmp;
>
> lockdep_assert_held_write(&vdev->memory_lock);
> + /*
> + * Holding memory_lock ensures a racing VMA fault observes
> + * priv->revoked properly.
> + */
Nit: This comment should appear before the lockdep_assert_held_write()
Also, it is slightly verbose.. (not against it though).
>
> list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm) {
> if (!get_file_active(&priv->dmabuf->file))
> @@ -549,6 +559,8 @@ void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
> if (revoked) {
> kref_put(&priv->kref, vfio_pci_dma_buf_done);
> wait_for_completion(&priv->comp);
> + unmap_mapping_range(priv->dmabuf->file->f_mapping,
> + 0, priv->size, 1);
Have we run this series with lockdep enabled?
I guess it'd be nice to check with lockdep once..
Apart from these,
Reviewed-by: Pranjal Shrivastava <praan(a)google.com>
Thanks,
Praan
On Wed, Jun 10, 2026 at 04:43:17PM +0100, Matt Evans wrote:
> This helper, vfio_pci_core_mmap_prep_dmabuf(), creates a single-range
> DMABUF for the purpose of mapping a PCI BAR. This is used in a future
> commit by VFIO's ordinary mmap() path.
>
> This function transfers ownership of the VFIO device fd to the
> DMABUF, which fput()s when it's released.
>
> Refactor the existing vfio_pci_core_feature_dma_buf() to split out
> export code common to the two paths, VFIO_DEVICE_FEATURE_DMA_BUF and
> this new VFIO_BAR mmap().
>
> Signed-off-by: Matt Evans <matt(a)ozlabs.org>
> ---
> drivers/vfio/pci/vfio_pci_dmabuf.c | 142 +++++++++++++++++++++++------
> drivers/vfio/pci/vfio_pci_priv.h | 5 +
> 2 files changed, 117 insertions(+), 30 deletions(-)
>
[...]
> +
> + /*
> + * Ownership of the DMABUF file transfers to the VMA so that
> + * other users can locate the DMABUF via a VA. Ownership of
> + * the original VFIO device file being mmap()ed transfers to
> + * priv, and is put when the DMABUF is released. This
> + * intentionally does not use get_file()/vma_set_file()
> + * because the references are already held, and ownership
> + * moves.
> + */
> + priv->vfile = vma->vm_file;
> + vma->vm_file = priv->dmabuf->file;
> + vma->vm_private_data = priv;
I appreciate this comment. Thanks for being clear!
Reviewed-by: Pranjal Shrivastava <praan(a)google.com>
Thanks,
Praan
In rocket_job_run(), after taking an extra fence reference for
job->done_fence via dma_fence_get(), the error paths have three bugs:
- The dma_fence reference held by job->done_fence is never released,
causing a reference leak.
- pm_runtime_get_sync() increments the usage counter even on failure,
but the error path does not decrement it, leaking the runtime PM
reference and preventing the NPU from suspending.
- A valid but unsignaled fence is returned to the DRM scheduler,
which triggers WARN("Fence ... released with pending signals!")
when the scheduler drops its reference.
Fix by replacing pm_runtime_get_sync() with pm_runtime_resume_and_get()
which auto-balances the usage counter on failure, releasing both fence
references on error, and returning ERR_PTR(ret) instead of the
unsignaled fence.
Cc: stable(a)vger.kernel.org
Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL")
Signed-off-by: ZhaoJinming <zhaojinming(a)uniontech.com>
---
drivers/accel/rocket/rocket_job.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c
index ac51bff39833..e8a073e22ac2 100644
--- a/drivers/accel/rocket/rocket_job.c
+++ b/drivers/accel/rocket/rocket_job.c
@@ -310,13 +310,22 @@ static struct dma_fence *rocket_job_run(struct drm_sched_job *sched_job)
dma_fence_put(job->done_fence);
job->done_fence = dma_fence_get(fence);
- ret = pm_runtime_get_sync(core->dev);
- if (ret < 0)
- return fence;
+ ret = pm_runtime_resume_and_get(core->dev);
+ if (ret < 0) {
+ dma_fence_put(job->done_fence);
+ job->done_fence = NULL;
+ dma_fence_put(fence);
+ return ERR_PTR(ret);
+ }
ret = iommu_attach_group(job->domain->domain, core->iommu_group);
- if (ret < 0)
- return fence;
+ if (ret < 0) {
+ pm_runtime_put(core->dev);
+ dma_fence_put(job->done_fence);
+ job->done_fence = NULL;
+ dma_fence_put(fence);
+ return ERR_PTR(ret);
+ }
scoped_guard(mutex, &core->job_lock) {
core->in_flight_job = job;
--
2.20.1
Cryptera Chain Signals is a leading specialist firm in cryptocurrency recovery, blockchain forensics, and digital asset tracing. Established to address the growing challenges of crypto fraud in 2026, the company combines cutting-edge technology with deep investigative expertise to help individuals and businesses recover stolen or lost cryptocurrency.
Our Mission
To provide victims of cryptocurrency scams, hacks, and wallet compromises with professional, ethical, and effective recovery solutions. We believe that while blockchain transactions are irreversible by design, advanced forensics and strategic coordination can often turn the tide in favour of rightful owners.
Core Services
1. Blockchain Forensics & Asset Tracing
Using proprietary AI-powered tools, Cryptera Chain Signals performs deep multi-chain analysis to track stolen funds across Bitcoin, Ethereum, Solana, and other major networks. We identify laundering patterns, mixer usage, cross-chain bridges, and peeling chains that many basic tools miss.
2. Scam Recovery & Fraud Investigation
Specialised support for victims of:
Phishing and wallet drain attacks
DeFi rug pulls and exit scams
Pig butchering and romance scams
Fake investment platforms
Business email compromise (BEC)
3. Wallet Access Recovery
Assistance with compromised accounts, lost credentials, and certain hardware/software wallet issues (where technically and legally feasible).
4. Exchange Coordination & Asset Freezing
Strong global relationships with major cryptocurrency exchanges enable rapid coordination for asset freezes and information requests when stolen funds are traceable to compliant platforms.
5. Forensic Reporting & Legal Support
Detailed, court-admissible reports that victims can use for:
Law enforcement complaints
Insurance claims
Civil litigation
Regulatory submissions
6. Post-Recovery Security Hardening
Comprehensive security audits and personalised recommendations to help clients prevent future losses.
Why Choose Cryptera Chain Signals
Advanced Technology: AI-driven analytics and proprietary tracing systems optimised for 2026 threats.
Transparency: Honest initial assessments with realistic expectations — no false guarantees.
Ethical Approach: Success-oriented fee structures and strict adherence to data protection laws (including GDPR).
Rapid Response: Critical speed advantage in time-sensitive cases.
Global Reach: Ability to coordinate across jurisdictions and major exchanges.
Client-Focused: Clear communication, secure client portals, and dedicated support throughout the process.
Our Approach
Every case begins with a confidential consultation. We review transaction details, wallet addresses, and available evidence before providing a professional opinion on recovery feasibility. Only cases with reasonable prospects move forward, ensuring we maintain high success rates in traceable scenarios.
Contact Cryptera Chain Signals
Website: https://www.crypterachainsignals.com/
Email: info(a)crypterachainsignals.com
Cryptera Chain Signals is committed to professionalism, integrity, and delivering meaningful results for victims of cryptocurrency crime. If you have lost digital assets, early action with experienced specialists offers the best opportunity for recovery.
> From: Matt Evans <matt(a)ozlabs.org>
> Sent: Wednesday, June 10, 2026 11:43 PM
>
> Since converting BAR mmap()s to using DMABUFs, we lose the original
> device path in /proc/<pid>/maps, lsof, etc. Generate a debug-oriented
> synthetic 'filename' based on the cdev, plus BDF, plus resource index.
>
> This applies only to BAR mappings via the VFIO device fd, as
> explicitly-exported DMABUFs are named by userspace via the
> DMA_BUF_SET_NAME ioctl.
>
> Signed-off-by: Matt Evans <matt(a)ozlabs.org>
Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>
> From: Matt Evans <matt(a)ozlabs.org>
> Sent: Wednesday, June 10, 2026 11:43 PM
>
> 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()
> zaps PTEs (used on the revocation and cleanup paths).
>
> CONFIG_VFIO_PCI_CORE now unconditionally depends on
> CONFIG_DMA_SHARED_BUFFER and CONFIG_PCI_P2PDMA_CORE. The
> CONFIG_VFIO_PCI_DMABUF feature conditionally includes support for
> VFIO_DEVICE_FEATURE_DMA_BUF, depending on the availability of
> CONFIG_PCI_P2PDMA.
>
> Signed-off-by: Matt Evans <matt(a)ozlabs.org>
Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>
with a nit:
> - vma->vm_private_data = vdev;
> + /*
> + * Create a DMABUF with a single range corresponding to this
> + * mapping, and wire it into vma->vm_private_data. The VMA's
> + * vm_file becomes that of the DMABUF, and the DMABUF takes
> + * ownership of the VFIO device file (put upon DMABUF
> + * release). This maintains the behaviour of a live VMA
> + * mapping holding the VFIO device file open.
> + */
> + ret = vfio_pci_core_mmap_prep_dmabuf(vdev, vma,
> + pci_resource_start(pdev, index),
> + req_len, index);
the comment is redundant as it's about internal logic of the callee
and is well covered by the comment there.
> From: Matt Evans <matt(a)ozlabs.org>
> Sent: Wednesday, June 10, 2026 11:43 PM
>
> This helper, vfio_pci_core_mmap_prep_dmabuf(), creates a single-range
> DMABUF for the purpose of mapping a PCI BAR. This is used in a future
> commit by VFIO's ordinary mmap() path.
>
> This function transfers ownership of the VFIO device fd to the
> DMABUF, which fput()s when it's released.
>
> Refactor the existing vfio_pci_core_feature_dma_buf() to split out
> export code common to the two paths, VFIO_DEVICE_FEATURE_DMA_BUF
> and
> this new VFIO_BAR mmap().
>
> Signed-off-by: Matt Evans <matt(a)ozlabs.org>
Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>
> From: Matt Evans <matt(a)ozlabs.org>
> Sent: Wednesday, June 10, 2026 11:43 PM
>
> +int vfio_pci_dma_buf_find_pfn(struct vfio_pci_dma_buf *priv,
> + struct vm_area_struct *vma,
> + unsigned long address,
> + unsigned int order,
> + unsigned long *out_pfn)
> +{
> + /*
> + * Given a VMA (start, end, pgoffs) and a fault address,
> + * search the corresponding DMABUF's phys_vec[] to find the
> + * range representing the address's offset into the VMA, and
> + * its PFN.
> + *
> + * The phys_vec[] ranges represent contiguous spans of VAs
> + * upwards from the buffer offset 0; the actual PFNs might be
> + * in any order, overlap/alias, etc. Calculate an offset of
> + * the desired page given VMA start/pgoff and address, then
> + * search upwards from 0 to find which span contains it.
> + *
> + * On success, a valid PFN for a page sized by 'order' is
> + * returned into out_pfn.
> + *
> + * Failure occurs if:
> + * - The page would cross the edge of the VMA
> + * - The page isn't entirely contained within a range
> + * - We find a range, but the final PFN isn't aligned to the
> + * requested order.
> + *
> + * (Upon failure, the caller is expected to try again with a
> + * smaller order; the tests above will always succeed for
> + * order=0 as the limit case.)
> + *
> + * It's suboptimal if DMABUFs are created with neigbouring
s/neigbouring/neighboring/
> + * ranges that are physically contiguous, since hugepages
> + * can't straddle range boundaries. (The construction of the
> + * ranges vector should merge such ranges.)
though the field is called 'phys_vec', removing 'vector' in description
is clearer here.
> + *
> + * Finally, vma_pgoff_adjust is used for a DMABUF representing
> + * a VFIO BAR mmap, which is created from the start of the
> + * offset region.
Elaborate it a little bit that the vm_pgoff is already counted in paddr
of phys_vec so it should be skipped when finding the pfn.
> + */
> +
> + const unsigned long pagesize = PAGE_SIZE << order;
> + unsigned long vma_off = ((vma->vm_pgoff - priv->vma_pgoff_adjust)
> <<
> + PAGE_SHIFT) & VFIO_PCI_OFFSET_MASK;
> + unsigned long rounded_page_addr = ALIGN_DOWN(address,
> pagesize);
> + unsigned long rounded_page_end = rounded_page_addr + pagesize;
> + unsigned long page_buf_offset;
> + unsigned long page_buf_offset_end;
what about "fault_offset[_end]"? page_buf is a bit confusing.
> + unsigned long range_buf_offset = 0;
could this be called 'range_start' then the 'range_start' in latter loop
is renamed to 'phys_start'?
Not strong... just feel such naming helps me understand the logic easier
> + unsigned int i;
> +
> + if (rounded_page_addr < vma->vm_start || rounded_page_end >
> vma->vm_end) {
> + if (order > 0)
> + return -EAGAIN;
> +
> + /* A fault address outside of the VMA is absurd. */
> + WARN(1, "Fault addr 0x%lx outside VMA 0x%lx-0x%lx\n",
> + address, vma->vm_start, vma->vm_end);
> + return -EFAULT;
> + }
> +
> + /*
> + * page_buff_offset[_end] is the span of DMABUF offsets
> + * corresponding to the faulting page:
> + */
if the naming is kept then s/page_buff_offset/page_buf_offset/
otherwise,
Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>
Hi all,
This series is based on previous RFCs/discussions:
Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/
RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/
RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/
The background/rationale is covered in more detail in the RFC cover
letters. The TL;DR is:
The goal is to enable userspace driver designs that use VFIO to export
DMABUFs representing subsets of PCI device BARs, and "vend" those
buffers from a primary process to other subordinate processes by fd.
These processes then mmap() the buffers and their access to the device
is isolated to the exported ranges. This is an improvement on sharing
the VFIO device fd to subordinate processes, which would allow
unfettered access.
This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd
to subordinate processes. Second, a new ioctl()-based revocation
mechanism is added to allow the primary process to forcibly revoke
access to previously-shared BAR spans, even if the subordinate
processes haven't cleanly exited.
(The related topic of safe delegation of iommufd control to the
subordinate processes is not addressed here, and is follow-up work.)
As well as isolation and revocation, another advantage to accessing a
BAR through a VMA backed by a DMABUF is that it's straightforward to
mmap() the buffer with access attributes, such as write-combining.
Feedback from the RFCs requested that, instead of creating
DMABUF-specific vm_ops and .fault paths, to go the whole way and
migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too,
resulting in a common vm_ops and fault handler for mmap()s of both the
VFIO device and explicitly-exported DMABUFs. This will help future
iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get
a DMABUF for a VFIO BAR as a DMA target.
mmap() conversion to use DMABUF underneath has been done for vfio-pci,
but not sub-drivers:
nvgrace-gpu's mmap() override path is unchanged; I kept this out of
scope for now not least because I don't have a thorough test setup
for this system. I would prefer to help the nvgrace-gpu maintainers
enable BAR mmap() DMABUFs themselves.
Notes on patches
================
PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
Later in the series, vfio-pci's mmap() is going to depend on
pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which
in turn depended on ZONE_DEVICE (which isn't available on 32-bit
and some archs, because they lack MEMORY_HOTPLUG and friends).
VFIO does _not_ require actual P2P to be present for basic mmap()
functionality, only for the optional CONFIG_DMA_SHARED_BUFFER
feature.
This splits P2PDMA into a CONFIG_PCI_P2PDMA_CORE (which currently
contains pcim_p2pdma_provider()) and an optional CONFIG_PCI_P2PDMA
(which depends on ZONE_DEVICE etc., and provides P2P
functionality).
vfio/pci: Add a helper to look up PFNs for DMABUFs
vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA
The first is for a DMABUF VMA fault handler to determine
arbitrary-sized PFNs from ranges in DMABUF. Secondly, refactor
DMABUF export for use by the existing export feature and add a new
helper that creates a DMABUF corresponding to a VFIO BAR mmap()
request.
vfio/pci: Convert BAR mmap() to use a DMABUF
The vfio-pci core mmap() creates a DMABUF with the helper, and the
vm_ops fault handler uses the other helper to resolve the fault.
Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE
needs to depend on CONFIG_DMA_SHARED_BUFFER. The
CONFIG_VFIO_PCI_DMABUF still conditionally enables the export
support code.
NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file
becomes that of the DMABUF which takes ownership of the device and
puts it on release. This maintains the existing behaviour of a VMA
keeping the VFIO device open.
BAR zapping then happens via the existing vfio_pci_dma_buf_move()
path, which now needs to unmap PTEs in the DMABUF's address_space.
vfio/pci: Provide a user-facing name for BAR mappings
There was a request for decent debug naming in /proc/<pid>/maps
etc. comparable to the existing VFIO names: since the VMAs are
DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical
to before. This is a user-visible change, but this patch at least
now gives us extra info on the BDF & BAR being mapped.
vfio/pci: Clean up BAR zap and revocation
In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete,
since it unmaps PTEs in the VFIO device address_space which is now
unused. This consolidates all calls (e.g. around reset) with the
neighbouring vfio_pci_dma_buf_move()s into new functions, to
revoke-zap/unrevoke.
!!! NOTE: the nvgrace-gpu driver continues to use its own private
vm_ops, fault handler, etc. for its special memregions, and these
DO still add PTEs to the VFIO device address_space. So, a
temporary flag, vdev->bar_needs_zap, maintains the old behaviour
for this use. At least this patch's consolidation makes it easy to
remove the remaining zap when this need goes away; a FIXME reminds
that this can be removed when nvgrace-gpu is converted.
vfio/pci: Support mmap() of a VFIO DMABUF
Adds mmap() for a DMABUF fd exported from vfio-pci.
It was a goal to keep the VFIO device fd lifetime behaviour
unchanged with respect to the DMABUFs. An application can close
all device fds, and this will revoke/clean up all DMABUFs; no
mappings or other access can be performed now. When enabling
mmap() of the DMABUFs, this means access through the VMA is also
revoked. This complicates the fault handler because whilst the
DMABUF exists, it has no guarantee that the corresponding VFIO
device is still alive. Adds synchronisation ensuring the vdev is
available before vdev->memory_lock is touched; this holds the
device registration so that even if the buffer has been cleaned up,
vdev hasn't been freed and so the lock can be safely taken.
(I decided against the alternative of preventing cleanup by holding
the VFIO device open if any DMABUFs exist, because it's both a
change of behaviour and less clean overall.)
I've added a chonky comment in place, happy to clarify more if you
have ideas.
This commit makes VFIO_PCI_CORE depend on PCI_P2PDMA_CORE (commit
1) to bring in (only) the P2PDMA provider code.
vfio/pci: Permanently revoke a DMABUF on request
By weight, this is mostly a rename of revoked to an enum, status.
There are now 3 states for a buffer, usable and revoked
temporary/permanent. A new VFIO device ioctl is added,
VFIO_DEVICE_PCI_DMABUF_REVOKE, which passes a DMABUF (exported from
that device) and permanently revokes it. Thus a userspace driver
can guarantee any downstream consumers of a shared fd are prevented
from accessing a BAR range, and that range can be reused.
The code doing revocation in vfio_pci_dma_buf_move() is moved,
unchanged, to a common function for use by _move() and the new
ioctl path.
Q: I can't think of a good reason to temporarily revoke/unrevoke
buffers from userspace, so didn't add a 'flags' field to the ioctl
struct. Easy to add if people think it's worthwhile for future
use.
vfio/pci: Add mmap() attributes to DMABUF feature
Adds a new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR.
After a DMABUF is exported, this feature ioctl() isused to set a
memory attribute that will be used by future mmap()s of the DMABUF
fd (i.e. it does nothing for any existing maps).
The default is UC, and via the feature one can specify CPU access
as WC. The attribute is an enum/scalar rather than
bitmap/cumulative. The attributes follow a "try-fail" model where
a client can request an attribute and either succeed or fail with
ENOTSUPP if it's unknown; if future attributes are
platform-specific then their support can be probed.
(Since it's just UC/WC for now, there is no reservation or numeric
structure to the namespace yet, but we could support
system/arch-specific values in future by carving out base +
arch-specific + IMPDEF ranges.)
Testing
=======
(The [RFC ONLY] userspace test program, for QEMU edu-plus, has been
dropped from the series, but can be found in the GitHub branch below.
It at least illustrates the export, map, revoke, attribute, and close
semantics interoperate.)
This code has been tested in mapping DMABUFs of single/multiple
ranges, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff >
0, revocation, shutdown/cleanup scenarios, and hugepage mappings seem
to work correctly. I've lightly tested WC mappings also (by observing
resulting PTEs as having the correct attributes...). No regressions
observed on the VFIO selftests, or on our internal vfio-pci
applications.
End
===
This is based on VFIO next (e.g. at b9285405c5f6).
These commits are on GitHub for easier browsing, along with
"[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test":
https://github.com/metamev/linux/compare/b9285405c5f6...metamev:linux:dev/m…
Thanks for reading,
Matt
================================================================================
Change log:
v2:
- Rebase on VFIO next, picking up Alex's
vfio_pci_dma_buf_move()/vfio_pci_dma_buf_cleanup() fixes, and
dropping "vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put"
- Added "PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE" so that the
newly-added vfio-pci hard dependency on the P2PDMA provider instead
pulls in the _CORE variant and not the full-fat CONFIG_PCI_P2PDMA.
This means that the core of vfio-pci does not need ZONE_DEVICE, but
if it's available then enabling P2PDMA in turn enables DMABUF
export. Fixes basic VFIO operation on 32b or other platforms without
ZONE_DEVICE.
- Fixed comment inaccuracy in vfio_pci_dma_buf_revoke() and cleaned
up vdev validity test.
- vfio_pci_dma_buf_find_pfn(): use PAGE_ALIGN(), better span variable
naming, OVF check
- Made vm_pgoffs use consistent (keeping the resource index at the
top and masking where offset is used). For BAR mmap, use new
vma_pgoff_adjust to create the DMABUF with the exact mmap()ed span
instead of from the start of the BAR with an invisible portion
before the mapping.
- Added VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR to set memory attributes,
instead of using the export `flags` field.
- vfio_pci_ioctl_reset: Moved vfio_pci_zap_revoke_bars()
(effectively, vfio_pci_dma_buf_move()) back after D0 transition.
Note, if a BAR zap is needed, it's done in this function so now
happens after this D0 transition with the _move; it was done before
it at the time of the memory_lock taking.
- Minimised vfio_pci_dma_buf_mmap() (removed redundant span check),
added READ_ONCE for memattr
- Misc fixes: comment in DMABUF name generation, removed superfluous
READ_ONCE from faulthandler
v1:
https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/
- Cleanup of the common DMABUF-aware VMA vm_ops fault handler and
export code.
- Fixed a lot of races, particularly faults racing with DMABUF
cleanup (if the VFIO device fds close, for example).
- Added nicer human-readable names for VFIO mmap() VMAs
RFCv2: Respin based on the feedback/suggestions:
https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/
- Transform the existing VFIO BAR mmap path to also use DMABUFs
behind the scenes, and then simply share that code for
explicitly-mapped DMABUFs. Jason wanted to go that direction to
enable iommufd VFIO type 1 emulation to pick up a DMABUF for an IO
mapping.
- Revoke buffers using a VFIO device fd ioctl
RFCv1:
https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/
Matt Evans (9):
PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
vfio/pci: Add a helper to look up PFNs for DMABUFs
vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA
vfio/pci: Convert BAR mmap() to use a DMABUF
vfio/pci: Provide a user-facing name for BAR mappings
vfio/pci: Clean up BAR zap and revocation
vfio/pci: Support mmap() of a VFIO DMABUF
vfio/pci: Permanently revoke a DMABUF on request
vfio/pci: Add mmap() attributes to DMABUF feature
drivers/pci/Kconfig | 10 +-
drivers/pci/Makefile | 2 +-
drivers/pci/p2pdma.c | 16 +
drivers/vfio/pci/Kconfig | 4 +-
drivers/vfio/pci/Makefile | 3 +-
drivers/vfio/pci/nvgrace-gpu/main.c | 5 +
drivers/vfio/pci/vfio_pci_config.c | 30 +-
drivers/vfio/pci/vfio_pci_core.c | 225 +++++++++---
drivers/vfio/pci/vfio_pci_dmabuf.c | 548 ++++++++++++++++++++++++----
drivers/vfio/pci/vfio_pci_priv.h | 57 ++-
include/linux/pci-p2pdma.h | 24 +-
include/linux/pci.h | 2 +-
include/linux/vfio_pci_core.h | 1 +
include/uapi/linux/vfio.h | 57 +++
14 files changed, 815 insertions(+), 169 deletions(-)
--
2.47.3
> From: Matt Evans <matt(a)ozlabs.org>
> Sent: Wednesday, June 10, 2026 11:43 PM
>
[...]
>
> vfio/pci: Support mmap() of a VFIO DMABUF
>
> Adds mmap() for a DMABUF fd exported from vfio-pci.
>
> It was a goal to keep the VFIO device fd lifetime behaviour
> unchanged with respect to the DMABUFs. An application can close
> all device fds, and this will revoke/clean up all DMABUFs; no
> mappings or other access can be performed now. When enabling
> mmap() of the DMABUFs, this means access through the VMA is also
> revoked. This complicates the fault handler because whilst the
> DMABUF exists, it has no guarantee that the corresponding VFIO
> device is still alive. Adds synchronisation ensuring the vdev is
> available before vdev->memory_lock is touched; this holds the
> device registration so that even if the buffer has been cleaned up,
> vdev hasn't been freed and so the lock can be safely taken.
>
> This commit makes VFIO_PCI_CORE depend on PCI_P2PDMA_CORE
> (commit
> 1) to bring in (only) the P2PDMA provider code.
the last sentence is stale as the dependency is now added in patch4.
>
> End
> ===
>
> This is based on VFIO next (e.g. at b9285405c5f6).
>
Sashiko failed to apply this series. Is there dependent work in vfio-next?
otherwise getting a Sashiko review is helpful here.