Linaro-mm-sig September 2026

linaro-mm-sig@lists.linaro.org

23 participants
63 discussions

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

2 weeks

Re: [PATCH v7 06/13] nvme-pci: implement dma-buf backed requests

by Christophe JAILLET

Le 28/09/2026 à 15:32, Pavel Begunkov a écrit : > Enable BIO_DMABUF_MAP backed requests. On registration we map the > dma-buf and store it as a prp list, which is then used to initialise > requests. All attached contexts are stored in a new list dmabuf_ctxs, > and additions/removals are synchronised with dmabuf_lock. > > Suggested-by: Keith Busch <kbusch(a)kernel.org> > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Hi, a few nitpick below, should it help. > --- > drivers/nvme/host/core.c | 12 ++ > drivers/nvme/host/nvme.h | 2 + > drivers/nvme/host/pci.c | 308 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 322 insertions(+) > [...] > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index a953c0697f99..e58bdd9a4098 100644 > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -27,6 +27,8 @@ > #include <linux/io-64-nonatomic-lo-hi.h> > #include <linux/io-64-nonatomic-hi-lo.h> > #include <linux/sed-opal.h> > +#include <linux/dma-buf-io.h> > +#include <linux/dma-resv.h> Move up, to keep better alphabetical order ? > > #include "trace.h" > #include "nvme.h" > @@ -318,6 +320,8 @@ struct nvme_dev { > bool hmb; > struct sg_table *hmb_sgt; > mempool_t *dmavec_mempool; > + struct list_head dmabuf_ctxs; > + struct mutex dmabuf_lock; > > /* shadow doorbell buffer support: */ > __le32 *dbbuf_dbs; > @@ -397,6 +401,13 @@ struct nvme_queue { > struct completion delete_done; > }; > > +struct nvme_dmabuf_map { > + struct dma_buf_io_map base; > + struct sg_table *sgt; > + unsigned nr_entries; > + dma_addr_t dma_list[]; Add __counted_by(nr_entries) and update nvme_dma_buf_io_map() so that nr_entries is set at the right time ? > +}; > + > /* bits for iod->flags */ > enum nvme_iod_flags { > /* this command has been aborted by the timeout handler */ ... > +static struct dma_buf_io_map *nvme_dma_buf_io_map(struct dma_buf_io_ctx *ctx) > +{ > + unsigned nr_entries = ctx->dmabuf->size / NVME_CTRL_PAGE_SIZE; > + struct nvme_dma_buf_io_ctx *nvme_ctx = ctx->dev_priv; > + struct dma_buf_attachment *attach = nvme_ctx->attach; > + unsigned long tmp, i = 0; > + struct nvme_dmabuf_map *map; > + struct scatterlist *sg; > + struct sg_table *sgt; > + int ret; > + > + dma_resv_assert_held(ctx->dmabuf->resv); > + > + map = kvmalloc_flex(*map, dma_list, nr_entries); > + if (!map) > + return ERR_PTR(-ENOMEM); > + > + sgt = dma_buf_map_attachment(attach, ctx->dir); > + if (IS_ERR(sgt)) { > + ret = PTR_ERR(sgt); > + sgt = NULL; > + goto err; > + } > + > + for_each_sgtable_dma_sg(sgt, sg, tmp) { > + dma_addr_t dma_addr = sg_dma_address(sg); > + unsigned long sg_len = sg_dma_len(sg); > + > + if ((sg_len % NVME_CTRL_PAGE_SIZE) || > + (dma_addr % NVME_CTRL_PAGE_SIZE)) { > + ret = -EINVAL; > + goto err; > + } > + while (sg_len) { > + map->dma_list[i++] = dma_addr; > + dma_addr += NVME_CTRL_PAGE_SIZE; > + sg_len -= NVME_CTRL_PAGE_SIZE; > + } > + } > + > + ret = dma_buf_io_init_map(ctx, &map->base, sgt); > + if (ret) > + goto err; > + map->nr_entries = nr_entries; > + map->sgt = sgt; > + return &map->base; > +err: > + if (sgt) > + dma_buf_unmap_attachment(attach, sgt, ctx->dir); > + kfree(map); kvfree()? > + return ERR_PTR(ret); > +} ... CJ

1 month

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

by Matt Evans

Hi all, The goal of this series 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. This is achieved by allowing the processes to mmap() the DMABUFs; their access to the device is isolated to the exported ranges. The primary userspace driver process can forcibly revoke access to previously-shared buffers upon cleanup (without requiring cooperation from the subordinate processes). This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow global access. See the RFCs for background. The existing VFIO PCI BAR mmap() becomes backed by a DMABUF too, keeping common vm_ops and fault handler for VMAs from 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. Below are per-patch notes & background info, and at the bottom are several related questions that reviewers may like to consider (worth at least skipping to #1, a possible bug). Notes on patches ================ 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. vfio/pci: Remove DMABUF export dependency on vdev->memory_lock In v5 of this series we discover that doing an export from the VFIO mmap() path (fundamental!) adds a dependency between mmap_lock and vdev->memory_lock(W) because export was using memory_lock(W) to protect the vdev->dmabufs list and state within, and a deadlock scenario leapt out to bite: https://lore.kernel.org/kvm/9a615f22-c0d4-46ae-9654-db11e94e5fec@ozlabs.org/ The suggestion was to add a dedicated mutex/rwsem specifically for the DMABUFs/list, which is cleaner than overloading memory_lock(W). But whilst export could now downgrade to holding memory_lock(R) to test __vfio_pci_memory_enabled(), a very similar deadlock can still arise due to a memory_lock(W) elsewhere depending on a prior memory_lock(R) to be released, and attempting to take memory_lock(R) will queue behind the (W) for fairness (effectively an R->R dependency). I'd overlooked that rwsem cannot guarantee multiple readers. To be able to export while holding mmap_lock, export cannot hold memory_lock at all. Instead of testing __vfio_pci_memory_enabled() (which tracks PCI_COMMAND.MSE and PM state), this patch tracks device-global DMABUF revocation state in a new vdev->bars_revoked flag updated by vfio_pci_dma_buf_move(). If an mmap() is somehow performed during a period when DMABUFs are all revoked, then the DMABUF is created revoked. Move() already bookends reset, PM transitions etc., so subsequent revocation state changes work as-is. This flag is also protected by the dmabuf_lock and thus memory_lock is not required to export. vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume On LOW_POWER entry, DMABUFs have a move(revoke=true), but the runtime resume path didn't un-revoke. This adds a corresponding move(revoke=false), which will later turn into vfio_pci_unrevoke_bars(). NOTE: the unrevoke is reordered _before_ the eventfd_signal() in vfio_pci_core_runtime_resume() to remove a window in which a waking waiter could have observed the DMABUF state as still revoked (or pm_runtime_engaged = true). (The UAPI docs state the event means the resume's complete, so observing otherwise seemed unintended.) Also, when DMABUFs are later mmap()ed, a waiter waking and taking a fault could have seen the unrevoked state and SIGBUS just before taking the memory_lock. (If the handler gets to acquire the lock, though, the resume sequence is complete, and the handler observes pm_runtime_engaged = false.) This fix is in this series because the issue will impact CPU access to the VMA as well (once they use DMABUFs), and so it's a strict dependency of later commits. dma-buf: Provide dma_buf_set_name() Makes dma_buf_set_name() available for use (by helper patch), taking a kernel-allocated string. The pre-existing local helper becomes a wrapper copying a __user string for the set-name ioctl. vfio/pci: Add a helper to look up PFNs for DMABUFs Adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Refactors DMABUF export for use by the existing export feature, and adds a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. 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 mmap()ed. The name is installed with the new dma_buf_set_name() above. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper above, 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. The DMABUF takes ownership of the device file and put()s it on release, which 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. NOTE: As local LLM reviews did, Sashiko might falsely worry about the DMABUF fd being obtained through /proc/pid/map_files and remapped, but the file is an anon inode and doesn't support the open op (-ENXIO) so AFAICT this is currently impossible. NOTE: A side-effect of this is that is_mergeable_vma() will be false between adjacent mappings of VFIO BARs; merging would require rebuilding a larger DMABUF representing the union, not just plugging the VMAs together. The DMABUF backing the BAR is an implicit/internal export, even when the CONFIG_VFIO_PCI_DMABUF feature is not included because CONFIG_PCI_P2PDMA is not available. Without P2PDMA, it's acceptable for the DMABUF to not have a P2PDMA provider. In this configuration, the VFIO DMABUF .attach prohibits any import, which avoids getting as far as a WARN in dma_buf_map_attachment(), which would fail without P2PDMA anyway. 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/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus sets the opt-out flag. 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; then, no mappings or other access can be performed. 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 the locks in vdev are touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the locks can be safely taken. vfio/pci: Revoke a DMABUF on request from userspace This is mostly a rename of `revoked` to an enum, `status`, and adding a third state for a buffer: usable, revoked temporary, revoked permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same 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. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function used by ..._move() and this new feature. Testing ======= (The [RFC ONLY] userspace test program, which drives a QEMU bochs-display function, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate. WIP on a follow-up with a proper vfio-selftests style test based on this -- this won't be part of this series.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Thanks to Alex Mastro for building a (WIP) testcase for the prior mmap_lock->memory_lock issue. Dear Reviewers, =============== Along the way several related issues came up that warrant more eyes, and I'd be grateful for your input: 1. If VFIO fd is opened O_RDONLY, it currently can't be mmap()ed (because PROT_WRITE is rejected in do_mmap(), and PROT_READ alone drops the VM_SHARED so VFIO's mmap rejects it). BUT it seems we can export a DMABUF from it, and then pass the resulting fd around for P2P writes. I don't know if this is intentional/relied on/a known limitation, or a bug? a) We could reject export w/ -EPERM unless the device fd's f_mode has O_RDWR, to reflect the RW abilities of P2P If we agree it's a bug, I want to do this fix (a), as we can now export a DMABUF RW from an O_RDONLY device fd and then succeed to mmap() the DMABUF with RW. (That said, even with an O_RDONLY device fd, the device state can still be changed/reset. But it feels cleaner to prevent export for a O_RDONLY device fd, and match the device fd mmap() behaviour.) In future, we could consider finer-grained RD/WR if there's a future goal to tie DMABUF permissions to, say, iommufd IOMMU_READ/IOMMU_WRITE permissions: b) Instead of just failing if !O_RDWR, we could limit the get_dma_buf.open_flags to the VFIO device fd's f_mode, such as: VFIO device fd perms: Export flags: Result: O_RDWR O_RDWR, O_RDONLY OK O_RDONLY O_RDONLY OK O_RDONLY O_RDWR -EPERM O_WRONLY * -EPERM * O_WRONLY -EPERM (Skipping WRONLY because a PROT_WRITE-only mmap() won't work, though it probably should be included for P2P.) 2. The mmap fault handler takes a bunch of locks non-interruptibly, and potentially depends on a lot of DMABUF-related activities completing. I'd had a go at converting them to interruptible/killable forms, but that revealed there seems to be a wider issue if move/revoke doesn't complete in a timely fashion (due to buggy importers). Where I got to was that just updating the fault handler won't fix the user experience of an unkillable task, and move()/revocation will need thought too. I don't intend to fix this here but wanted to start discussion so we can address it in a follow up. There's now a dependency between mmap_lock in the fault handler and the DMABUF resv (which might take a while to resolve), though revocation will be rare in practice. 3. vfio_basic_config_write() has an error path if vfio_default_config_write() fails that releases memory_lock but doesn't un-revoke BARs in the case of PCI_COMMAND.MSE being cleared. When can the write fail, in practice, perhaps surprise removal? The effect on this series would be: a write of MSE=0 revokes BARs, vconfig[PCI_COMMAND]'s MSE becomes 0, but if the physical write fails then the physical MSE remains 1 and BAR VMAs stay revoked. This seemed a mess; fixing isn't as simple as un-revoking on the error path since vfio_default_config_write() has already trampled vconfig so that'd need unwinding. It felt like a catastrophic scenario where BARs staying revoked isn't a bad outcome, but want to hear your experience of the likelihood of this issue. 4. The exchange of a VFIO fd mmap()'s vma->vm_file with an implicitly created DMABUF's file has implications on LSM. For example, an mmap will be checked against the policy for a VFIO fd, but a subsequent mprotect() relates to the policy of the DMABUF file (which is anon/unique to the mapping). This is pretty confusing. END === This is based on v7.3-rc4 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/v7.3-rc4...dev/mev/vfio-dmabuf-mma… Thanks for reading, Matt ================================================================================ Changelog: v7: - Rebased, v7.3-rc4 - "dma-buf: Export dma_buf_set_name()" is now "dma-buf: Provide dma_buf_set_name()": reworded commit message with rationale, and indicate it is only expected to be used by exporters. Remove static helper for user ioctl & copy from user inline in the ioctl. - "vfio/pci: Permanently revoke a DMABUF on request" is now "vfio/pci: Revoke a DMABUF on request from userspace", with a clarified commit message, and removal of "temporary/permanent" language. This still replaces the priv->revoked flag with an enum/third state, named OK/REVOKED for the existing two. The new state, DEAD, is "sticky" from the VFIO-internal perspective, meaning it prevents any of the move-style transitions from REVOKED back to OK, guaranteeing that a DEAD buffer cannot ever be attached/mapped by a new or existing importer. Clarified language around attach vs map to not imply a racing import will be detached; it might attach, but cannot map (and has no existing maps) after the ioctl returns. - Reworded several commit messages for more clarity/brevity. - "vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA": As of the recent e8efdf02d3a97 ("vfio: Enable cdev noiommu mode under iommufd") dev_name() can be much larger (e.g. noiommu_vfio1048575) and the discovery that drivers/pci/controller/vmd.c (others?) could create a domain up to MAX_INT means there isn't a nice way to guarantee a debug name is available across all cdev names and maximum sizes of all properties (e.g. 1M cdevs, 4G domains). So, removed the cdev name from the debug name construction, which now looks like 'vfio:0001:02:03.4/5'. The cdev can be fished out of sysfs given the domain+BDF, and it's still useful debug. Adjusted comments & commit message. v6: https://lore.kernel.org/all/20260911214200.33793-1-matt@ozlabs.org/ v5: https://lore.kernel.org/all/20260715174737.15287-1-matt@ozlabs.org/ v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/ v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ Matt Evans (9): vfio/pci: Remove DMABUF export dependency on vdev->memory_lock vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume dma-buf: Provide dma_buf_set_name() 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: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Revoke a DMABUF on request from userspace drivers/dma-buf/dma-buf.c | 78 ++- drivers/vfio/pci/Kconfig | 4 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 14 +- drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 222 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 609 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 54 +- include/linux/dma-buf.h | 2 + include/linux/vfio_pci_core.h | 3 + include/uapi/linux/vfio.h | 24 + 11 files changed, 856 insertions(+), 187 deletions(-) -- 2.50.1 (Apple Git-155)

1 month

[PATCH v8 00/23] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the client chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, expose the provider to dma-buf importers, and let mlx5 ask rather than assume. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v8: - Added extra Reviewed-by from Logan. - Added patches to take care of ATS per-device vs. per-mapping option - Link to v7: https://patch.msgid.link/20260920-fix-p2p-acs-v4-0-v7-0-ca0828ab697c@nvidia… Changes in v7: - Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing after p2pmem fix. - Split dmabuf patch. - Tushar retested the series, so added his Tested-by. - Added Logan's ROB tags and fixed minor documentation issues pointed by him. - Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi… Changes in v6: - Changed DMABUF to use callbacks and not directly stored pointer. - Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia… Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (23): PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing dma-buf: Let importers ask how peer-to-peer traffic is routed vfio/pci: Hand out the P2PDMA provider behind a dma-buf RDMA/uverbs: Hand out the P2PDMA provider behind a dma-buf RDMA/mlx5: Ask P2PDMA whether ATS takes a direct peer-to-peer route PCI/P2PDMA: Let a client declare that it selects ATS per mapping RDMA/mlx5: Declare to P2PDMA that ATS is selected per memory key PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled PCI/P2PDMA: Test the routing of clients with ATS enabled Documentation/admin-guide/kernel-parameters.txt | 15 +- Documentation/driver-api/pci/p2pdma.rst | 80 ++ drivers/dma-buf/dma-buf-mapping.c | 39 + drivers/infiniband/core/uverbs_std_types_dmabuf.c | 12 + drivers/infiniband/hw/mlx5/main.c | 2 + drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 +- drivers/infiniband/hw/mlx5/mr.c | 47 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 704 ++++++++++++++++-- drivers/pci/pci.c | 7 +- drivers/pci/pci.h | 31 + drivers/pci/pci_acs_test.c | 860 ++++++++++++++++++++++ drivers/pci/quirks.c | 6 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 12 + include/linux/dma-buf-mapping.h | 3 + include/linux/dma-buf.h | 19 + include/linux/pci-p2pdma.h | 62 +- 18 files changed, 1828 insertions(+), 123 deletions(-) --- base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72 change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 prerequisite-message-id: <20260830-batch-p2p-fixes-v1-0-5044e8dfbe2e(a)nvidia.com> prerequisite-patch-id: 6b25c7fcf164cdfc14e9fac5b908d97fcf6509d7 prerequisite-patch-id: 0d083c281001365aae4b35544cf28891a6ab9a96 prerequisite-patch-id: bfd9dabf271f3cc9a3a61f46387d20c20311363d prerequisite-patch-id: fad0275efc722830fc591509506c0a5e4f581073 prerequisite-patch-id: 0c83bee688fec1f6d1564654df7c630fa6a4a978 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 month

Re: [PATCH v6 01/13] dma-buf: introduce initial file I/O infrastructure

by Matthew Brost

On Wed, Sep 30, 2026 at 01:48:49PM +0100, Pavel Begunkov wrote: > On 9/30/26 11:08, Pavel Begunkov wrote: > > On 9/30/26 04:00, Matthew Brost wrote: > > > On Mon, Sep 21, 2026 at 02:38:45PM +0100, Pavel Begunkov wrote: > > ...>> +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > > > > +{ > > > > + struct dma_buf *dmabuf = ctx->dmabuf; > > > > + struct dma_buf_io_map *map; > > > > + long ret; > > > > + > > > > + guard(mutex)(&ctx->map_create_mutex); > > > > + > > > > + scoped_guard(mutex, &ctx->map_mutex) { > > > > + if (ctx->maps_killed) > > > > + return ERR_PTR(-ENOENT); > > > > + /* recheck under the lock in case it has already been re-created */ > > > > + map = __dma_buf_io_get_map(ctx); > > > > + if (map) > > > > + return map; > > > > + } > > > > + > > > > + dma_buf_io_wait_active_maps(ctx); > > > > + > > > > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); > > > > + if (ret) > > > > + return ERR_PTR(ret); > > > > + > > > > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > > > > + true, MAX_SCHEDULE_TIMEOUT); > > > > + if (ret <= 0) { > > > > + if (!ret) > > > > + ret = -EAGAIN; > > > > + dma_resv_unlock(dmabuf->resv); > > > > + return ERR_PTR(ret); > > > > + } > > > > + > > > > + map = ctx->dev_ops->map(ctx); > > > > > > I'm playing around this code now. > > > > > > I think you need the dma_resv_wait_timeout after the 'map'? > > > > > > If a device doesn't support p2p ->map() will typically trigger an async > > > migrate to system memory and data will be moving but the map is valid - > > > Xe 100% does this, I checked AMDGPU and fairly confident it has the same > > > async behavior. > > > > There is a wait right before because I read somewhere in dma-buf > > comments that I need to do that, sounds a bit odd if I need to > > wait on fences before and after. I can add it, just curious how > > come that other dma_buf_map_attachment() callers don't need to do > > that. Or maybe they wait somewhere else? In GPU drivers, when we receive a foreign object and map it in Xe or AMDGPU, this logic sits deep in the stack. However, the top-level call is typically ttm_bo_validate(), which in both drivers eventually resolves to the TTM ->move() vfunc. That path calls dma_buf_map_attachment(), which in turn invokes the dma-buf's ->map() callback. That ->map() callback can trigger a asynchronous move on a different device, where the top-level call is again ttm_bo_validate(). We then end up back in the TTM ->move() vfunc, where kernel fences are installed. I realize that's a lot of layers, but the call chain can end up looking like this. Now we have a mapping and an object with kernel fences attached. Before the object can be used by either the exec IOCTL (batch buffer submission), the VM bind IOCTL (mapping into the GPU address space), or a CPU page fault (not relevant for dma-bufs since they cannot be CPU-mapped, but a useful example of a normal BO move), we wait on those kernel fences. In the case of the exec IOCTL or VM bind IOCTL, the kernel fences are added as dependencies to a drm_sched job, delaying its execution until the fences signal. That is where the wait occurs. In the case of a CPU page fault, the kernel waits directly on the fences before installing the CPU page mappings. So the TL;DR is if you want to immediately hand back a valid mapping, the kernel fences must be waited on before returning after ->map() call. Matt > > I can't find it, so maybe it was the comment below and I mixed > sth up back then. I'll move it after ->map(). > > > * Note that for non-dynamic exporters the driver must guarantee that > * that the memory is available for use and cleared of any old data by > * the time this function returns. Drivers which pipeline their buffer > * moves internally must wait for all moves and clears to complete. > * Dynamic exporters do not need to follow this rule: For non-dynamic > * importers the buffer is already pinned through @pin, which has the > * same requirements. Dynamic importers otoh are required to obey the > * dma_resv fences. > * > > -- > Pavel Begunkov >

1 month

Re: [PATCH v6 01/13] dma-buf: introduce initial file I/O infrastructure

by Matthew Brost

On Mon, Sep 21, 2026 at 02:38:45PM +0100, Pavel Begunkov wrote: > The goal is to be able to natively use dma-buf in the read-write / IO > path. This patch adds basic building blocks serving as a glue and API > between drivers and upper layer subsystems providing the uAPI. Later > patches implement it for NVMe raw block devices and expose it to the > user space via io_uring. > > There are two main objects. struct dma_buf_io_ctx and struct > dma_buf_io_map. The ctx is used during initial registration and serves > as an interface between the upper layer user like io_uring and to the > importer subsystem / driver. The map represents the actual dma map > established for the target device[s] with dma_buf_map_attachment() and > stored in a device specific format. The context is created via a new > file operation ->init_dma_buf_io_ctx. > > The ctx-map separation exists to support map invalidation (see > dma_buf_io_invalidate_mappings()). A ctx can create > multiple maps during its lifetime, but there can only be no more than > one (active) map attached to it. Invalidation drops the active map > if present, and the next map will only be attempted to be created > once there is a new request that wants to use the dma-buf IO ctx. > > The primary task of the dma_buf_io_map object is to count requests > using it and to wait for their completion when we want to destroy the > DMA map. > > [un]mapping and any work with dma addresses is delegated to the > importer driver via an ops table stored in the ctx, see struct > dma_buf_io_ops. Only the target driver / subsystem knows about devices > it wants to use the dma-buf with, especially in case of multi-device > filesystems or stacking in the future. > > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dma-buf-io.c | 219 +++++++++++++++++++++++++++++++++++ > include/linux/dma-buf-io.h | 113 ++++++++++++++++++ > include/linux/fs.h | 2 + > 4 files changed, 335 insertions(+), 1 deletion(-) > create mode 100644 drivers/dma-buf/dma-buf-io.c > create mode 100644 include/linux/dma-buf-io.h > > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index b25d7550bacf..523731b0f83e 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,6 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0-only > obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ > - dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o > + dma-fence-unwrap.o dma-resv.o dma-buf-mapping.o dma-buf-io.o > obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_DMABUF_HEAPS) += heaps/ > obj-$(CONFIG_SYNC_FILE) += sync_file.o > diff --git a/drivers/dma-buf/dma-buf-io.c b/drivers/dma-buf/dma-buf-io.c > new file mode 100644 > index 000000000000..8312637a299f > --- /dev/null > +++ b/drivers/dma-buf/dma-buf-io.c > @@ -0,0 +1,219 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common infrastructure for supporing dma-buf in the I/O path. > + * > + * Copyright (C) 2026 Pavel Begunkov <asml.silence(a)gmail.com> > + */ > +#include <linux/dma-buf-io.h> > +#include <linux/dma-resv.h> > + > +static void dma_buf_io_put_ctx(struct dma_buf_io_ctx *ctx) > +{ > + might_sleep(); > + > + if (WARN_ON_ONCE(rcu_dereference_protected(ctx->map, true))) > + return; > + > + ctx->dev_ops->release(ctx); > + > + dma_buf_put(ctx->dmabuf); > + mutex_destroy(&ctx->map_mutex); > + mutex_destroy(&ctx->map_create_mutex); > + kfree(ctx); > +} > + > +static void dma_buf_io_map_release_work(struct work_struct *work) > +{ > + struct dma_buf_io_map *map = container_of(work, struct dma_buf_io_map, > + release_work); > + struct dma_buf_io_ctx *ctx = map->ctx; > + struct dma_buf *dmabuf = ctx->dmabuf; > + > + dma_resv_lock(dmabuf->resv, NULL); > + ctx->dev_ops->unmap(ctx, map); > + dma_resv_unlock(dmabuf->resv); > + > + percpu_ref_exit(&map->refs); > + kfree(map); > + > + atomic_dec(&ctx->all_maps); > + wake_up(&ctx->maps_wq); > +} > + > +static void dma_buf_io_map_refs_release(struct percpu_ref *ref) > +{ > + struct dma_buf_io_map *map = container_of(ref, struct dma_buf_io_map, refs); > + struct dma_buf_io_ctx *ctx = map->ctx; > + > + /* There are no more requests using the map. */ > + atomic_dec(&ctx->active_maps); > + wake_up(&ctx->maps_wq); > + > + /* might sleep, use a worker */ > + INIT_WORK(&map->release_work, dma_buf_io_map_release_work); > + queue_work(system_percpu_wq, &map->release_work); > +} > + > +static void dma_buf_io_wait_active_maps(struct dma_buf_io_ctx *ctx) > +{ > + wait_event(ctx->maps_wq, atomic_read(&ctx->active_maps) == 0); > +} > + > +static void dma_buf_io_wait_maps(struct dma_buf_io_ctx *ctx) > +{ > + wait_event(ctx->maps_wq, atomic_read(&ctx->all_maps) == 0); > +} > + > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map, > + struct sg_table *sgt) > +{ > + unsigned seg_shift = ~0U; > + struct scatterlist *sg; > + unsigned long tmp; > + int ret; > + > + for_each_sgtable_dma_sg(sgt, sg, tmp) > + seg_shift = min(seg_shift, __ffs(sg_dma_len(sg))); > + > + ret = percpu_ref_init(&map->refs, dma_buf_io_map_refs_release, 0, > + GFP_KERNEL); > + if (ret) > + return ret; > + map->min_seg_shift = seg_shift; > + map->ctx = ctx; > + return 0; > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_init_map, "DMA_BUF"); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf *dmabuf = ctx->dmabuf; > + struct dma_buf_io_map *map; > + long ret; > + > + guard(mutex)(&ctx->map_create_mutex); > + > + scoped_guard(mutex, &ctx->map_mutex) { > + if (ctx->maps_killed) > + return ERR_PTR(-ENOENT); > + /* recheck under the lock in case it has already been re-created */ > + map = __dma_buf_io_get_map(ctx); > + if (map) > + return map; > + } > + > + dma_buf_io_wait_active_maps(ctx); > + > + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); > + if (ret) > + return ERR_PTR(ret); > + > + ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL, > + true, MAX_SCHEDULE_TIMEOUT); > + if (ret <= 0) { > + if (!ret) > + ret = -EAGAIN; > + dma_resv_unlock(dmabuf->resv); > + return ERR_PTR(ret); > + } > + > + map = ctx->dev_ops->map(ctx); I'm playing around this code now. I think you need the dma_resv_wait_timeout after the 'map'? If a device doesn't support p2p ->map() will typically trigger an async migrate to system memory and data will be moving but the map is valid - Xe 100% does this, I checked AMDGPU and fairly confident it has the same async behavior. Matt > + dma_resv_unlock(dmabuf->resv); > + > + if (IS_ERR(map)) > + return map; > + if (WARN_ON_ONCE(!map->min_seg_shift)) > + return ERR_PTR(-EFAULT); > + > + atomic_inc(&ctx->active_maps); > + atomic_inc(&ctx->all_maps); > + /* get a reference for the caller */ > + percpu_ref_get(&map->refs); > + > + scoped_guard(mutex, &ctx->map_mutex) > + rcu_assign_pointer(ctx->map, map); > + return map; > +} > + > +static void dma_buf_io_kill_maps(struct dma_buf_io_ctx *ctx, bool final) > +{ > + struct dma_buf_io_map *map; > + > + scoped_guard(mutex, &ctx->map_mutex) { > + if (final) > + ctx->maps_killed = true; > + > + map = rcu_dereference_protected(ctx->map, > + lockdep_is_held(&ctx->map_mutex)); > + if (!map) > + return; > + rcu_assign_pointer(ctx->map, NULL); > + percpu_ref_kill(&map->refs); > + } > +} > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx) > +{ > + dma_buf_io_kill_maps(ctx, false); > + dma_buf_io_wait_active_maps(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_invalidate_mappings, "DMA_BUF"); > + > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx) > +{ > + /* Remove and wait for the last map, there should be no new ones. */ > + dma_buf_io_kill_maps(ctx, true); > + dma_buf_io_wait_maps(ctx); > + dma_buf_io_put_ctx(ctx); > +} > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir, > + struct dma_buf_io_ctx **out_ctx) > +{ > + struct dma_buf_io_ctx *ctx; > + int ret; > + > + if (!file->f_op->init_dma_buf_io_ctx) > + return -EOPNOTSUPP; > + > + ctx = kmalloc_obj(*ctx); > + if (!ctx) > + return -ENOMEM; > + > + memset(ctx, 0, sizeof(*ctx)); > + ctx->dir = dir; > + ctx->dmabuf = dmabuf; > + get_dma_buf(dmabuf); > + mutex_init(&ctx->map_mutex); > + mutex_init(&ctx->map_create_mutex); > + atomic_set(&ctx->active_maps, 0); > + atomic_set(&ctx->all_maps, 0); > + init_waitqueue_head(&ctx->maps_wq); > + > + ret = file->f_op->init_dma_buf_io_ctx(file, ctx); > + if (ret) { > + kfree(ctx); > + dma_buf_put(dmabuf); > + return ret; > + } > + > + if (WARN_ON_ONCE(!ctx->dev_ops || > + !ctx->dev_ops->map || > + !ctx->dev_ops->unmap || > + !ctx->dev_ops->release)) > + return -EINVAL; > + > + *out_ctx = ctx; > + return 0; > +} > + > +void dma_buf_io_detach(struct dma_buf_io_ctx *ctx) > +{ > + guard(mutex)(&ctx->map_create_mutex); > + > + dma_buf_io_kill_maps(ctx, true); > + dma_buf_io_wait_maps(ctx); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_io_detach, "DMA_BUF"); > diff --git a/include/linux/dma-buf-io.h b/include/linux/dma-buf-io.h > new file mode 100644 > index 000000000000..5ea92fc78582 > --- /dev/null > +++ b/include/linux/dma-buf-io.h > @@ -0,0 +1,113 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __DMA_BUF_IO_H__ > +#define __DMA_BUF_IO_H__ > + > +#include <linux/dma-buf.h> > + > +struct dma_buf_io_ctx; > +struct dma_buf_io_map; > + > +struct dma_buf_io_ops { > + /* > + * Create a new map for the given ctx. Called with the reservation > + * lock held. > + */ > + struct dma_buf_io_map *(*map)(struct dma_buf_io_ctx *ctx); > + > + /* > + * Clean up device specific parts of the @map. Called with the > + * reservation lock held. > + */ > + void (*unmap)(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map); > + > + /* > + * The user tries to destroy the ctx. Release all device specific > + * parts of the token. > + */ > + void (*release)(struct dma_buf_io_ctx *); > +}; > + > +struct dma_buf_io_map { > + /* > + * Counts attached requests and other users. Device specific unmapping > + * is deferred until all refs are dropped. > + */ > + struct percpu_ref refs; > + /* > + * Shift for the minimum segment size of the mapping. > + */ > + unsigned min_seg_shift; > + > + struct work_struct release_work; > + struct dma_buf_io_ctx *ctx; > +}; > + > +struct dma_buf_io_ctx { > + struct dma_buf_io_map __rcu *map; > + struct dma_buf *dmabuf; > + enum dma_data_direction dir; > + > + /* synchronises map reassignment */ > + struct mutex map_mutex; > + struct mutex map_create_mutex; > + /* maps that may still be in use. */ > + atomic_t active_maps; > + atomic_t all_maps; > + struct wait_queue_head maps_wq; > + bool maps_killed; > + > + void *dev_priv; > + const struct dma_buf_io_ops *dev_ops; > +}; > + > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir, > + struct dma_buf_io_ctx **ctx); > +void dma_buf_io_ctx_release(struct dma_buf_io_ctx *ctx); > + > +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx); > + > +static inline struct dma_buf_io_map * > +__dma_buf_io_get_map(struct dma_buf_io_ctx *ctx) > +{ > + struct dma_buf_io_map *map; > + > + guard(rcu)(); > + > + map = rcu_dereference(ctx->map); > + if (unlikely(!map || !percpu_ref_tryget_live_rcu(&map->refs))) > + return NULL; > + > + return map; > +} > + > +static inline struct dma_buf_io_map * > +dma_buf_io_get_map(struct dma_buf_io_ctx *ctx, bool nowait) > +{ > + struct dma_buf_io_map *map; > + > + map = __dma_buf_io_get_map(ctx); > + if (likely(map)) > + return map; > + > + if (nowait) > + return ERR_PTR(-EAGAIN); > + return dma_buf_io_create_map(ctx); > +} > + > +static inline void dma_buf_io_map_drop(struct dma_buf_io_map *map) > +{ > + percpu_ref_put(&map->refs); > +} > + > +/* > + * Device API > + */ > + > +void dma_buf_io_invalidate_mappings(struct dma_buf_io_ctx *ctx); > +int dma_buf_io_init_map(struct dma_buf_io_ctx *ctx, struct dma_buf_io_map *map, > + struct sg_table *sgt); > +void dma_buf_io_detach(struct dma_buf_io_ctx *ctx); > + > +#endif > diff --git a/include/linux/fs.h b/include/linux/fs.h > index f9d1e05e8ae6..05c1ff495732 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1914,6 +1914,7 @@ struct dir_context { > #define COPY_FILE_SPLICE (1 << 0) > > struct io_uring_cmd; > +struct dma_buf_io_ctx; > struct offset_ctx; > > struct file_operations { > @@ -1960,6 +1961,7 @@ struct file_operations { > int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, > unsigned int poll_flags); > int (*mmap_prepare)(struct vm_area_desc *); > + int (*init_dma_buf_io_ctx)(struct file *, struct dma_buf_io_ctx *); > } __randomize_layout; > > /* Supports async buffered reads */ > -- > 2.54.0 >

1 month

Re: [PATCH v7 01/13] dma-buf: introduce initial file I/O infrastructure

by Christophe JAILLET

Le 28/09/2026 à 15:32, Pavel Begunkov a écrit : > The goal is to be able to natively use dma-buf in the read-write / IO > path. This patch adds basic building blocks serving as a glue and API > between drivers and upper layer subsystems providing the uAPI. Later > patches implement it for NVMe raw block devices and expose it to the > user space via io_uring. > > There are two main objects. struct dma_buf_io_ctx and struct > dma_buf_io_map. The ctx is used during initial registration and serves > as an interface between the upper layer user like io_uring and to the > importer subsystem / driver. The map represents the actual dma map > established for the target device[s] with dma_buf_map_attachment() and > stored in a device specific format. The context is created via a new > file operation ->init_dma_buf_io_ctx. > > The ctx-map separation exists to support map invalidation (see > dma_buf_io_invalidate_mappings()). A ctx can create > multiple maps during its lifetime, but there can only be no more than > one (active) map attached to it. Invalidation drops the active map > if present, and the next map will only be attempted to be created > once there is a new request that wants to use the dma-buf IO ctx. > > The primary task of the dma_buf_io_map object is to count requests > using it and to wait for their completion when we want to destroy the > DMA map. > > [un]mapping and any work with dma addresses is delegated to the > importer driver via an ops table stored in the ctx, see struct > dma_buf_io_ops. Only the target driver / subsystem knows about devices > it wants to use the dma-buf with, especially in case of multi-device > filesystems or stacking in the future. > > Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> > --- Hi, a few nitpicks below, should it help > +static void dma_buf_io_kill_maps(struct dma_buf_io_ctx *ctx, bool final) > +{ > + struct dma_buf_io_map *map; > + > + scoped_guard(mutex, &ctx->map_mutex) { guard() is enough. This saves indentation. > + if (final) > + ctx->maps_killed = true; > + > + map = rcu_dereference_protected(ctx->map, > + lockdep_is_held(&ctx->map_mutex)); > + if (!map) > + return; > + rcu_assign_pointer(ctx->map, NULL); > + percpu_ref_kill(&map->refs); > + } > +} ... > +int dma_buf_io_ctx_create(struct file *file, > + struct dma_buf *dmabuf, > + enum dma_data_direction dir, > + struct dma_buf_io_ctx **out_ctx) > +{ > + struct dma_buf_io_ctx *ctx; > + int ret; > + > + if (!file->f_op->init_dma_buf_io_ctx) > + return -EOPNOTSUPP; > + > + ctx = kmalloc_obj(*ctx); kzalloc_obj() and save the memset() below > + if (!ctx) > + return -ENOMEM; > + > + memset(ctx, 0, sizeof(*ctx)); > + ctx->dir = dir; > + ctx->dmabuf = dmabuf; > + get_dma_buf(dmabuf); > + mutex_init(&ctx->map_mutex); > + mutex_init(&ctx->map_create_mutex); > + atomic_set(&ctx->active_maps, 0); > + atomic_set(&ctx->all_maps, 0); > + refcount_set(&ctx->refs, 1); > + init_waitqueue_head(&ctx->maps_wq); > + > + ret = file->f_op->init_dma_buf_io_ctx(file, ctx); > + if (ret) { > + kfree(ctx); > + dma_buf_put(dmabuf); > + return ret; > + } > + > + if (WARN_ON_ONCE(!ctx->dev_ops || > + !ctx->dev_ops->map || > + !ctx->dev_ops->unmap || > + !ctx->dev_ops->release)) > + return -EINVAL; > + > + *out_ctx = ctx; > + return 0; > +} ... CJ

1 month

Re: [PATCH v2] udmabuf: respect the device's maximum segment size

by Christian König

On 9/29/26 07:48, Karl Mehltretter wrote: > get_sg_table() merges physically contiguous pages without accounting > for the mapping device's maximum segment size. This affects both > importer mappings and the udmabuf misc device mapping used for CPU > access. > > With DMA_API_DEBUG enabled, DMA_BUF_IOCTL_SYNC on a 64 MiB udmabuf > reports: > > DMA-API: misc udmabuf: mapping sg segment longer than device claims to > support [len=65884160] [max=65536] > > Use sg_alloc_table_from_pages_segment() with the mapping device's > maximum segment size. Return -EINVAL if the limit is smaller than > PAGE_SIZE because the page-based allocator cannot honor it. > > Before commit 5bf888673e0d ("udmabuf: Do not create malformed > scatterlists"), each entry covered one page. > > Fixes: 5bf888673e0d ("udmabuf: Do not create malformed scatterlists") > Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > Assisted-by: LLM > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> > --- > > Notes: > Changes in v2: > - Return -EINVAL when the maximum segment size reported by the device is > smaller than PAGE_SIZE instead of clamping it. (Christian) > - Add Jason Gunthorpe's Reviewed-by tag. > > Tested on v7.3-rc4-70-gfe2ec83746e5 in QEMU (x86_64, TCG) with > DMA_API_DEBUG (all_errors=1) and DMABUF_DEBUG, A/B against the same > base: > > before after > DMA_BUF_IOCTL_SYNC, 64 MiB udmabuf 1 report 0 > vivid import, 4 MiB udmabuf 2 reports 0 > vivid import, 2 MiB hugetlb udmabuf 2 reports 0 > frames captured 5/5 5/5 > > vb2-dma-contig rejected the non-contiguous import in both runs. > > For v2, a focused importer advertising PAGE_SIZE / 2 returned > -EINVAL under KASAN and DMA_API_DEBUG. No warning, BUG, or DMA-API > report was emitted. > > drivers/dma-buf/udmabuf.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index df6dd00462423..018937435356e 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -133,15 +133,22 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > { > struct udmabuf *ubuf = buf->priv; > struct sg_table *sg; > + unsigned int max_segment; > int ret; > > + max_segment = dma_get_max_seg_size(dev); > + /* The SG allocator requires a segment limit of at least PAGE_SIZE. */ > + if (max_segment < PAGE_SIZE) > + return ERR_PTR(-EINVAL); > + > sg = kzalloc_obj(*sg); > if (!sg) > return ERR_PTR(-ENOMEM); > > - ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, 0, > - ubuf->pagecount << PAGE_SHIFT, > - GFP_KERNEL); > + ret = sg_alloc_table_from_pages_segment(sg, ubuf->pages, ubuf->pagecount, > + 0, ubuf->pagecount << PAGE_SHIFT, > + max_segment, > + GFP_KERNEL); > if (ret < 0) > goto err_alloc; > > > base-commit: fe2ec83746e501645709761605c2464a44fd2929

1 month

Re: [PATCH] udmabuf: respect the device's maximum segment size

by Christian König

On 9/26/26 09:12, Karl Mehltretter wrote: > get_sg_table() merges physically contiguous pages without accounting > for the mapping device's maximum segment size. This affects both > importer mappings and the udmabuf misc device mapping used for CPU > access. > > With DMA_API_DEBUG enabled, DMA_BUF_IOCTL_SYNC on a 64 MiB udmabuf > reports: > > DMA-API: misc udmabuf: mapping sg segment longer than device claims to support [len=65884160] [max=65536] > > Use sg_alloc_table_from_pages_segment() with the mapping device's > maximum segment size. Keep a PAGE_SIZE minimum because the allocator > warns and returns -EINVAL for smaller limits. > > Before commit 5bf888673e0d ("udmabuf: Do not create malformed > scatterlists"), each entry covered one page. > > Fixes: 5bf888673e0d ("udmabuf: Do not create malformed scatterlists") > Assisted-by: LLM > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> > --- > > Notes: > Tested on v7.3-rc4-70-gfe2ec83746e5 in QEMU (x86_64, TCG) with > DMA_API_DEBUG (all_errors=1) and DMABUF_DEBUG, A/B against the same > base: > > before after > DMA_BUF_IOCTL_SYNC, 64 MiB udmabuf 1 report 0 > vivid import, 4 MiB udmabuf 2 reports 0 > vivid import, 2 MiB hugetlb udmabuf 2 reports 0 > frames captured 5/5 5/5 > > vb2-dma-contig rejected the non-contiguous import in both runs. > > drivers/dma-buf/udmabuf.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index df6dd00462423..09f1eb8432f19 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -139,9 +139,13 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > if (!sg) > return ERR_PTR(-ENOMEM); > > - ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, 0, > - ubuf->pagecount << PAGE_SHIFT, > - GFP_KERNEL); > + /* The SG allocator requires a segment limit of at least PAGE_SIZE. */ > + ret = sg_alloc_table_from_pages_segment(sg, ubuf->pages, ubuf->pagecount, > + 0, ubuf->pagecount << PAGE_SHIFT, > + max_t(unsigned int, > + dma_get_max_seg_size(dev), > + PAGE_SIZE), Please return -EINVAL instead when dma_get_max_seg_size() returns that the segment size is smaller than a page. In general I think that the sg_alloc_table_from_pages_segment() approach is because of the broken design of the old DMA API. Stuff like that should be handled by the iterator going over the DMA segments instead. But yeah that is not something you can fix in one patch. So apart from the error handling the patch looks good to me. Regards, Christian. > + GFP_KERNEL); > if (ret < 0) > goto err_alloc; >

1 month

Re: [PATCH v2] udmabuf: respect the device's maximum segment size

by Jason Gunthorpe

On Tue, Sep 29, 2026 at 08:56:01AM +0200, Karl Mehltretter wrote: > On Tue, Sep 29, 2026 at 06:00:27AM +0000, sashiko-bot(a)kernel.org wrote: > > On architectures with a 256KB PAGE_SIZE (such as Hexagon or PowerPC), this > > new validation evaluates to 65536 < 262144, unconditionally returning > > -EINVAL and breaking all CPU mappings. > > Right, the misc device has no dma_parms, so it gets the 64K default and > sync fails with 256K pages I would ignore this, it seems fictional to me, and if someone really needs to support this rediculous combination it should be done inside sg_alloc_table_from_pages_segment(:) > The misc device has no real segment limit, so for v3 I'll give it > dma_parms with an unlimited max segment size and keep the -EINVAL for > importers that report a limit below PAGE_SIZE. The params have to come from the *importing* device, not the udmabuf misc device. You don't get to control what they are, and there is no reason to put a dma_parms on a misc deivce. Jason

1 month

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig September 2026