Linaro-mm-sig June 2026

linaro-mm-sig@lists.linaro.org

95 participants
462 discussions

Re: [PATCH v3 4/9] vfio/pci: Convert BAR mmap() to use a DMABUF

by Pranjal Shrivastava

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

1 week, 2 days

Re: [PATCH v3 3/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA

by Pranjal Shrivastava

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

1 week, 2 days

[PATCH v6 1/2] accel/rocket: Fix error path handling in rocket_job_run()

by ZhaoJinming

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

1 week, 2 days

What Is Cryptera Chain Signals

by morganhawkman68＠gmail.com

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.

1 week, 2 days

Re: [PATCH v3 5/9] vfio/pci: Provide a user-facing name for BAR mappings

by Tian, Kevin

> 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>

1 week, 2 days

Re: [PATCH v3 4/9] vfio/pci: Convert BAR mmap() to use a DMABUF

by Tian, Kevin

> 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.

1 week, 2 days

Re: [PATCH v3 3/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA

by Tian, Kevin

> 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>

1 week, 2 days

Re: [PATCH v3 2/9] vfio/pci: Add a helper to look up PFNs for DMABUFs

by Tian, Kevin

> 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>

1 week, 2 days

[PATCH v2 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

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

1 week, 2 days

Re: [PATCH v3 0/9] vfio/pci: Add mmap() for DMABUFs

by Tian, Kevin

> 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.

1 week, 2 days

← Newer
1
...
38
39
40
41
42
43
44
...
47
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig June 2026