This patch introduces a new heap driver to expose DT non‑reusable
"shared-dma-pool" coherent regions as dma-buf heaps, so userspace can
allocate buffers from each reserved, named region.
Because these regions are device‑dependent, each heap instance binds a
heap device to its reserved‑mem region via a newly introduced helper
function -namely, of_reserved_mem_device_init_with_mem()- so coherent
allocations use the correct dev->dma_mem.
Charging to cgroups for these buffers is intentionally left out to keep
review focused on the new heap; I plan to follow up based on Eric’s [1]
and Maxime’s [2] work on dmem charging from userspace.
This series also makes the new heap driver modular, in line with the CMA
heap change in [3].
[1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2…
[2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.…
[3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812…
Signed-off-by: Albert Esteve <aesteve(a)redhat.com>
---
Changes in v2:
- Removed dmem charging parts
- Moved coherent heap registering logic to coherent.c
- Made heap device a member of struct dma_heap
- Split dma_heap_add logic into create/register, to be able to
access the stored heap device before registered.
- Avoid platform device in favour of heap device
- Added a wrapper to rmem device_init() op
- Switched from late_initcall() to module_init()
- Made the coherent heap driver modular
- Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4…
---
Albert Esteve (5):
dma-buf: dma-heap: split dma_heap_add
of_reserved_mem: add a helper for rmem device_init op
dma-buf: heaps: Add Coherent heap to dmabuf heaps
dma: coherent: register to coherent heap
dma-buf: heaps: coherent: Turn heap into a module
John Stultz (1):
dma-buf: dma-heap: Keep track of the heap device struct
drivers/dma-buf/dma-heap.c | 138 +++++++++--
drivers/dma-buf/heaps/Kconfig | 9 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/coherent_heap.c | 429 ++++++++++++++++++++++++++++++++++
drivers/of/of_reserved_mem.c | 27 ++-
include/linux/dma-heap.h | 16 ++
include/linux/dma-map-ops.h | 7 +
include/linux/of_reserved_mem.h | 8 +
kernel/dma/coherent.c | 34 +++
9 files changed, 642 insertions(+), 27 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9
Best regards,
--
Albert Esteve <aesteve(a)redhat.com>
This version splits the change up to be more bisectable. It first adds a
new kino_t typedef and a new "PRIino" macro to hold the width specifier
for format strings. The conversion is done, and then everything is
changed to remove the new macro and typedef.
I also missed a few places in the earlier set. This one hopefully does a
bit more thorough job.
My thanks and apologies to everyone who sent R-b/A-b for the v1 series.
v2 breaks a lot of the changes up into two patches so many of those
didn't carry over. Please resend those if you're still OK with it.
The entire pile is in the "iino-u64" branch of my tree, if anyone is
interested in testing this:
https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
Original cover letter follows:
----------------------8<-----------------------
Christian said [1] to "just do it" when I proposed this, so here we are!
For historical reasons, the inode->i_ino field is an unsigned long,
which means that it's 32 bits on 32 bit architectures. This has caused a
number of filesystems to implement hacks to hash a 64-bit identifier
into a 32-bit field, and deprives us of a universal identifier field for
an inode.
This patchset changes the inode->i_ino field from an unsigned long to a
u64. This shouldn't make any material difference on 64-bit hosts, but
32-bit hosts will see struct inode grow by at least 4 bytes. This could
have effects on slabcache sizes and field alignment.
The bulk of the changes are to format strings and tracepoints, since the
kernel itself doesn't care that much about the i_ino field. The first
patch changes some vfs function arguments, so check that one out
carefully.
With this change, we may be able to shrink some inode structures. For
instance, struct nfs_inode has a fileid field that holds the 64-bit
inode number. With this set of changes, that field could be eliminated.
I'd rather leave that sort of cleanups for later just to keep this
simple.
Much of this set was generated by LLM, but I attributed it to myself
since I consider this to be in the "menial tasks" category of LLM usage.
[1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@…
Signed-off-by: Jeff Layton <jlayton(a)kernel.org>
---
Changes in v2:
- Use a typedef and macro and do the change in two steps to make it cleanly bisectable
- Fix check_for_busy_inodes() in fscrypt
- Added patch to reorganize tracepoint structs for better packing
- Added patch to change sock.sk_ino to u64
- Added patch to clean up internal handling of inode numbers in audit subsystem
- Drop some unnecessary casts
- Link to v1: https://lore.kernel.org/r/20260226-iino-u64-v1-0-ccceff366db9@kernel.org
---
Jeff Layton (110):
vfs: introduce kino_t typedef and PRIino format macro
vfs: widen inode hash/lookup functions to u64
audit: widen ino fields to u64
net: change sock.sk_ino and sock_i_ino() to u64
trace: store i_ino as u64 instead of ino_t/unsigned long
trace: reorder TP_STRUCT__entry fields for better packing on 32-bit
ext4: use PRIino format for i_ino
jbd2: use PRIino format for i_ino
f2fs: use PRIino format for i_ino
lockd: use PRIino format for i_ino
nfs: use PRIino format for i_ino
nfsd: use PRIino format for i_ino
locks: use PRIino format for i_ino
proc: use PRIino format for i_ino
nilfs2: use PRIino format for i_ino
9p: use PRIino format for i_ino
affs: use PRIino format for i_ino
afs: use PRIino format for i_ino
autofs: use PRIino format for i_ino
befs: use PRIino format for i_ino
bfs: use PRIino format for i_ino
cachefiles: use PRIino format for i_ino
ceph: use PRIino format for i_ino
coda: use PRIino format for i_ino
cramfs: use PRIino format for i_ino
ecryptfs: use PRIino format for i_ino
efs: use PRIino format for i_ino
exportfs: use PRIino format for i_ino
ext2: use PRIino format for i_ino
freevxfs: use PRIino format for i_ino
hfs: use PRIino format for i_ino
hfsplus: use PRIino format for i_ino
hpfs: use PRIino format for i_ino
isofs: use PRIino format for i_ino
jffs2: use PRIino format for i_ino
jfs: use PRIino format for i_ino
minix: use PRIino format for i_ino
nsfs: use PRIino format for i_ino
ntfs3: use PRIino format for i_ino
ocfs2: use PRIino format for i_ino
orangefs: use PRIino format for i_ino
overlayfs: use PRIino format for i_ino
qnx4: use PRIino format for i_ino
qnx6: use PRIino format for i_ino
ubifs: use PRIino format for i_ino
udf: use PRIino format for i_ino
ufs: use PRIino format for i_ino
zonefs: use PRIino format for i_ino
security: use PRIino format for i_ino
drm/amdgpu: use PRIino format for i_ino
fsnotify: use PRIino format for i_ino
net: use PRIino format for i_ino
uprobes: use PRIino format for i_ino
dma-buf: use PRIino format for i_ino
fscrypt: use PRIino format for i_ino
fsverity: use PRIino format for i_ino
iomap: use PRIino format for i_ino
net: use PRIino format for i_ino
vfs: use PRIino format for i_ino
vfs: change kino_t from unsigned long to u64
ext4: replace PRIino with %llu/%llx format strings
jbd2: replace PRIino with %llu/%llx format strings
f2fs: replace PRIino with %llu/%llx format strings
lockd: replace PRIino with %llu/%llx format strings
nfs: replace PRIino with %llu/%llx format strings
nfsd: replace PRIino with %llu/%llx format strings
proc: replace PRIino with %llu/%llx format strings
nilfs2: replace PRIino with %llu/%llx format strings
9p: replace PRIino with %llu/%llx format strings
affs: replace PRIino with %llu/%llx format strings
afs: replace PRIino with %llu/%llx format strings
autofs: replace PRIino with %llu/%llx format strings
befs: replace PRIino with %llu/%llx format strings
bfs: replace PRIino with %llu/%llx format strings
cachefiles: replace PRIino with %llu/%llx format strings
ceph: replace PRIino with %llu/%llx format strings
coda: replace PRIino with %llu/%llx format strings
cramfs: replace PRIino with %llu/%llx format strings
ecryptfs: replace PRIino with %llu/%llx format strings
efs: replace PRIino with %llu/%llx format strings
exportfs: replace PRIino with %llu/%llx format strings
ext2: replace PRIino with %llu/%llx format strings
freevxfs: replace PRIino with %llu/%llx format strings
hfs: replace PRIino with %llu/%llx format strings
hfsplus: replace PRIino with %llu/%llx format strings
hpfs: replace PRIino with %llu/%llx format strings
isofs: replace PRIino with %llu/%llx format strings
jffs2: replace PRIino with %llu/%llx format strings
jfs: replace PRIino with %llu/%llx format strings
minix: replace PRIino with %llu/%llx format strings
ntfs3: replace PRIino with %llu/%llx format strings
ocfs2: replace PRIino with %llu/%llx format strings
orangefs: replace PRIino with %llu/%llx format strings
overlayfs: replace PRIino with %llu/%llx format strings
qnx4: replace PRIino with %llu/%llx format strings
qnx6: replace PRIino with %llu/%llx format strings
ubifs: replace PRIino with %llu/%llx format strings
udf: replace PRIino with %llu/%llx format strings
ufs: replace PRIino with %llu/%llx format strings
zonefs: replace PRIino with %llu/%llx format strings
fscrypt: replace PRIino with %llu/%llx format strings
fsverity: replace PRIino with %llu/%llx format strings
iomap: replace PRIino with %llu/%llx format strings
fsnotify: replace PRIino with %llu/%llx format strings
security: replace PRIino with %llu/%llx format strings
drm/amdgpu: replace PRIino with %llu/%llx format strings
dma-buf: replace PRIino with %llu/%llx format strings
net: replace PRIino with %llu/%llx format strings
uprobes: replace PRIino with %llu/%llx format strings
vfs: remove kino_t typedef and PRIino format macro
drivers/dma-buf/dma-buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +-
fs/9p/vfs_addr.c | 4 +-
fs/9p/vfs_inode.c | 6 +-
fs/9p/vfs_inode_dotl.c | 6 +-
fs/affs/amigaffs.c | 8 +-
fs/affs/bitmap.c | 2 +-
fs/affs/dir.c | 2 +-
fs/affs/file.c | 20 +-
fs/affs/inode.c | 12 +-
fs/affs/namei.c | 14 +-
fs/affs/symlink.c | 2 +-
fs/afs/dir.c | 10 +-
fs/afs/dir_search.c | 2 +-
fs/afs/dynroot.c | 2 +-
fs/afs/inode.c | 2 +-
fs/autofs/inode.c | 2 +-
fs/befs/linuxvfs.c | 28 +-
fs/bfs/dir.c | 4 +-
fs/cachefiles/io.c | 6 +-
fs/cachefiles/namei.c | 12 +-
fs/cachefiles/xattr.c | 2 +-
fs/ceph/crypto.c | 4 +-
fs/coda/dir.c | 2 +-
fs/coda/inode.c | 2 +-
fs/cramfs/inode.c | 2 +-
fs/crypto/crypto.c | 2 +-
fs/crypto/hooks.c | 2 +-
fs/crypto/keyring.c | 4 +-
fs/crypto/keysetup.c | 2 +-
fs/dcache.c | 4 +-
fs/ecryptfs/crypto.c | 6 +-
fs/ecryptfs/file.c | 2 +-
fs/efs/inode.c | 6 +-
fs/eventpoll.c | 2 +-
fs/exportfs/expfs.c | 4 +-
fs/ext2/dir.c | 10 +-
fs/ext2/ialloc.c | 9 +-
fs/ext2/inode.c | 2 +-
fs/ext2/trace.h | 8 +-
fs/ext2/xattr.c | 14 +-
fs/ext4/dir.c | 2 +-
fs/ext4/ext4.h | 4 +-
fs/ext4/extents.c | 8 +-
fs/ext4/extents_status.c | 28 +-
fs/ext4/fast_commit.c | 8 +-
fs/ext4/ialloc.c | 10 +-
fs/ext4/indirect.c | 2 +-
fs/ext4/inline.c | 14 +-
fs/ext4/inode.c | 22 +-
fs/ext4/ioctl.c | 4 +-
fs/ext4/mballoc.c | 6 +-
fs/ext4/migrate.c | 2 +-
fs/ext4/move_extent.c | 20 +-
fs/ext4/namei.c | 10 +-
fs/ext4/orphan.c | 16 +-
fs/ext4/page-io.c | 10 +-
fs/ext4/super.c | 22 +-
fs/ext4/xattr.c | 10 +-
fs/f2fs/compress.c | 4 +-
fs/f2fs/dir.c | 2 +-
fs/f2fs/extent_cache.c | 8 +-
fs/f2fs/f2fs.h | 6 +-
fs/f2fs/file.c | 12 +-
fs/f2fs/gc.c | 2 +-
fs/f2fs/inline.c | 4 +-
fs/f2fs/inode.c | 48 ++--
fs/f2fs/namei.c | 8 +-
fs/f2fs/node.c | 12 +-
fs/f2fs/recovery.c | 10 +-
fs/f2fs/xattr.c | 10 +-
fs/freevxfs/vxfs_bmap.c | 4 +-
fs/fserror.c | 2 +-
fs/hfs/catalog.c | 2 +-
fs/hfs/extent.c | 4 +-
fs/hfs/inode.c | 4 +-
fs/hfsplus/attributes.c | 10 +-
fs/hfsplus/catalog.c | 2 +-
fs/hfsplus/dir.c | 6 +-
fs/hfsplus/extents.c | 6 +-
fs/hfsplus/inode.c | 8 +-
fs/hfsplus/super.c | 6 +-
fs/hfsplus/xattr.c | 10 +-
fs/hpfs/dir.c | 4 +-
fs/hpfs/dnode.c | 4 +-
fs/hpfs/ea.c | 4 +-
fs/hpfs/inode.c | 4 +-
fs/inode.c | 49 ++--
fs/iomap/ioend.c | 2 +-
fs/iomap/trace.h | 8 +-
fs/isofs/compress.c | 2 +-
fs/isofs/dir.c | 2 +-
fs/isofs/inode.c | 6 +-
fs/isofs/namei.c | 2 +-
fs/jbd2/journal.c | 4 +-
fs/jbd2/transaction.c | 2 +-
fs/jffs2/dir.c | 4 +-
fs/jffs2/file.c | 4 +-
fs/jffs2/fs.c | 18 +-
fs/jfs/inode.c | 2 +-
fs/jfs/jfs_imap.c | 2 +-
fs/jfs/jfs_metapage.c | 2 +-
fs/lockd/svclock.c | 8 +-
fs/lockd/svcsubs.c | 2 +-
fs/locks.c | 6 +-
fs/minix/inode.c | 10 +-
fs/nfs/dir.c | 20 +-
fs/nfs/file.c | 8 +-
fs/nfs/filelayout/filelayout.c | 8 +-
fs/nfs/flexfilelayout/flexfilelayout.c | 8 +-
fs/nfs/inode.c | 6 +-
fs/nfs/nfs4proc.c | 4 +-
fs/nfs/pnfs.c | 12 +-
fs/nfsd/export.c | 2 +-
fs/nfsd/nfs4state.c | 4 +-
fs/nfsd/nfsfh.c | 4 +-
fs/nfsd/vfs.c | 2 +-
fs/nilfs2/alloc.c | 10 +-
fs/nilfs2/bmap.c | 2 +-
fs/nilfs2/btnode.c | 2 +-
fs/nilfs2/btree.c | 12 +-
fs/nilfs2/dir.c | 12 +-
fs/nilfs2/direct.c | 4 +-
fs/nilfs2/gcinode.c | 2 +-
fs/nilfs2/inode.c | 8 +-
fs/nilfs2/mdt.c | 2 +-
fs/nilfs2/namei.c | 2 +-
fs/nilfs2/segment.c | 2 +-
fs/notify/fdinfo.c | 4 +-
fs/nsfs.c | 4 +-
fs/ntfs3/super.c | 2 +-
fs/ocfs2/alloc.c | 2 +-
fs/ocfs2/aops.c | 4 +-
fs/ocfs2/dir.c | 8 +-
fs/ocfs2/dlmfs/dlmfs.c | 10 +-
fs/ocfs2/extent_map.c | 12 +-
fs/ocfs2/inode.c | 2 +-
fs/ocfs2/quota_local.c | 2 +-
fs/ocfs2/refcounttree.c | 10 +-
fs/ocfs2/xattr.c | 4 +-
fs/orangefs/inode.c | 2 +-
fs/overlayfs/export.c | 2 +-
fs/overlayfs/namei.c | 4 +-
fs/overlayfs/util.c | 2 +-
fs/pipe.c | 2 +-
fs/proc/fd.c | 2 +-
fs/proc/task_mmu.c | 4 +-
fs/qnx4/inode.c | 4 +-
fs/qnx6/inode.c | 2 +-
fs/ubifs/debug.c | 8 +-
fs/ubifs/dir.c | 28 +-
fs/ubifs/file.c | 28 +-
fs/ubifs/journal.c | 6 +-
fs/ubifs/super.c | 16 +-
fs/ubifs/tnc.c | 4 +-
fs/ubifs/xattr.c | 14 +-
fs/udf/directory.c | 18 +-
fs/udf/file.c | 2 +-
fs/udf/inode.c | 12 +-
fs/udf/namei.c | 8 +-
fs/udf/super.c | 2 +-
fs/ufs/balloc.c | 6 +-
fs/ufs/dir.c | 10 +-
fs/ufs/ialloc.c | 6 +-
fs/ufs/inode.c | 18 +-
fs/ufs/ufs_fs.h | 6 +-
fs/ufs/util.c | 2 +-
fs/verity/init.c | 2 +-
fs/zonefs/super.c | 8 +-
fs/zonefs/trace.h | 18 +-
include/linux/audit.h | 2 +-
include/linux/fs.h | 28 +-
include/net/sock.h | 4 +-
include/trace/events/cachefiles.h | 18 +-
include/trace/events/ext4.h | 423 +++++++++++++++--------------
include/trace/events/f2fs.h | 172 ++++++------
include/trace/events/filelock.h | 34 +--
include/trace/events/filemap.h | 20 +-
include/trace/events/fs_dax.h | 20 +-
include/trace/events/fsverity.h | 30 +-
include/trace/events/hugetlbfs.h | 42 +--
include/trace/events/netfs.h | 8 +-
include/trace/events/nilfs2.h | 12 +-
include/trace/events/readahead.h | 18 +-
include/trace/events/timestamp.h | 16 +-
include/trace/events/writeback.h | 162 +++++------
kernel/audit.h | 9 +-
kernel/audit_fsnotify.c | 4 +-
kernel/audit_watch.c | 8 +-
kernel/auditsc.c | 2 +-
kernel/events/uprobes.c | 4 +-
net/ax25/af_ax25.c | 2 +-
net/bluetooth/af_bluetooth.c | 4 +-
net/can/bcm.c | 2 +-
net/ipv4/ping.c | 2 +-
net/ipv4/raw.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/udp.c | 2 +-
net/ipv6/datagram.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
net/key/af_key.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/netlink/diag.c | 2 +-
net/netrom/af_netrom.c | 4 +-
net/packet/af_packet.c | 2 +-
net/packet/diag.c | 2 +-
net/phonet/socket.c | 4 +-
net/rose/af_rose.c | 4 +-
net/sctp/proc.c | 4 +-
net/socket.c | 2 +-
net/unix/af_unix.c | 2 +-
net/unix/diag.c | 6 +-
net/x25/x25_proc.c | 4 +-
net/xdp/xsk_diag.c | 2 +-
security/apparmor/apparmorfs.c | 4 +-
security/integrity/integrity_audit.c | 2 +-
security/ipe/audit.c | 2 +-
security/lsm_audit.c | 10 +-
security/selinux/hooks.c | 10 +-
security/smack/smack_lsm.c | 12 +-
220 files changed, 1181 insertions(+), 1181 deletions(-)
---
base-commit: 842cfe0733c5a03982a7ae496de6fdc0dd661a41
change-id: 20260224-iino-u64-b44a3a72543c
Best regards,
--
Jeff Layton <jlayton(a)kernel.org>
Introduce a new accel driver for the Neutron Neural Processing Unit
(NPU), along with associated dt-bindings and DTS node.
The first patch extends the GEM DMA helper APIs to allow bidirectional
mapping of non-coherent DMA buffers. While not part of the Neutron
driver, it's a prerequisite allowing us to use the GEM DMA helper.
Neutron is a Neural Processing Unit from NXP, providing machine
learning (ML) acceleration for edge AI applications. Neutron is
integrated on NXP SoCs such as the i.MX95.
The NPU consists of the following:
- RISC-V core running a proprietary firmware
- One or more Neutron cores, representing the main computation
engine performing ML operations
- Dedicated fast memory (TCM)
- DMA engine that handles data transfers between DDR and TCM
The firmware is closed source and distributed as a binary here [1].
The Neutron software stack also contains a userspace library [1] and
a LiteRT custom delegate [2] that allow integration with standard
LiteRT tools.
[1] https://github.com/nxp-upstream/neutron/tree/upstream
[2] https://github.com/nxp-imx/tflite-neutron-delegate
Signed-off-by: Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com>
---
Ioana Ciocoi-Radulescu (9):
drm/gem-dma: Add flag for bidirectional mapping of non-coherent GEM DMA buffers
accel/neutron: Add documentation for NXP Neutron accelerator driver
dt-bindings: npu: Add bindings for NXP Neutron
accel/neutron: Add driver for NXP Neutron NPU
accel/neutron: Add GEM buffer object support
accel/neutron: Add mailbox support
accel/neutron: Add job submission IOCTL
accel/neutron: Add logging support
arm64: dts: imx95: Add Neutron node
Documentation/accel/index.rst | 1 +
Documentation/accel/neutron/index.rst | 12 +
Documentation/accel/neutron/neutron.rst | 131 ++++++++
.../devicetree/bindings/npu/nxp,imx95-neutron.yaml | 95 ++++++
MAINTAINERS | 10 +
arch/arm64/boot/dts/freescale/imx95.dtsi | 28 ++
drivers/accel/Kconfig | 1 +
drivers/accel/Makefile | 3 +-
drivers/accel/neutron/Kconfig | 16 +
drivers/accel/neutron/Makefile | 12 +
drivers/accel/neutron/neutron_debugfs.c | 34 ++
drivers/accel/neutron/neutron_debugfs.h | 15 +
drivers/accel/neutron/neutron_device.c | 239 ++++++++++++++
drivers/accel/neutron/neutron_device.h | 158 +++++++++
drivers/accel/neutron/neutron_driver.c | 262 +++++++++++++++
drivers/accel/neutron/neutron_driver.h | 16 +
drivers/accel/neutron/neutron_gem.c | 115 +++++++
drivers/accel/neutron/neutron_gem.h | 14 +
drivers/accel/neutron/neutron_job.c | 367 +++++++++++++++++++++
drivers/accel/neutron/neutron_job.h | 45 +++
drivers/accel/neutron/neutron_mailbox.c | 47 +++
drivers/accel/neutron/neutron_mailbox.h | 42 +++
drivers/gpu/drm/drm_gem_dma_helper.c | 6 +-
include/drm/drm_gem_dma_helper.h | 3 +
include/uapi/drm/neutron_accel.h | 130 ++++++++
25 files changed, 1799 insertions(+), 3 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260226-neutron-c435e39d167f
Best regards,
--
Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com>
Hi,
The recent introduction of heaps in the optee driver [1] made possible
the creation of heaps as modules.
It's generally a good idea if possible, including for the already
existing system and CMA heaps.
The system one is pretty trivial, the CMA one is a bit more involved,
especially since we have a call from kernel/dma/contiguous.c to the CMA
heap code. This was solved by turning the logic around and making the
CMA heap call into the contiguous DMA code.
Let me know what you think,
Maxime
1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l…
Signed-off-by: Maxime Ripard <mripard(a)kernel.org>
---
Changes in v2:
- Collect tags
- Don't export dma_contiguous_default_area anymore, but export
dev_get_cma_area instead
- Mentioned that heap modules can't be removed
- Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09…
---
Maxime Ripard (9):
dma: contiguous: Turn heap registration logic around
dma: contiguous: Make dev_get_cma_area() a proper function
dma: contiguous: Make dma_contiguous_default_area static
mm: cma: Export dev_get_cma_area()
mm: cma: Export cma_alloc and cma_release
mm: cma: Export cma_get_name
dma-buf: heaps: Export mem_accounting parameter
dma-buf: heaps: cma: Turn the heap into a module
dma-buf: heaps: system: Turn the heap into a module
drivers/dma-buf/dma-heap.c | 1 +
drivers/dma-buf/heaps/Kconfig | 4 ++--
drivers/dma-buf/heaps/cma_heap.c | 21 +++++----------------
drivers/dma-buf/heaps/system_heap.c | 5 +++++
include/linux/dma-map-ops.h | 14 ++++++--------
kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++---
mm/cma.c | 3 +++
7 files changed, 56 insertions(+), 29 deletions(-)
---
base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916
change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a
Best regards,
--
Maxime Ripard <mripard(a)kernel.org>
Hi all,
There were various suggestions in the September 2025 thread "[TECH
TOPIC] vfio, iommufd: Enabling user space drivers to vend more
granular access to client processes" [0], and LPC discussions, around
improving the situation for multi-process userspace driver designs.
This RFC series implements some of these ideas.
Background: Multi-process USDs
==============================
The userspace driver scenario discussed in that thread involves a
primary process driving a PCIe function through VFIO/iommufd, which
manages the function-wide ownership/lifecycle. The function is
designed to provide multiple distinct programming interfaces (for
example, several independent MMIO register frames in one function),
and the primary process delegates control of these interfaces to
multiple independent client processes (which do the actual work).
This scenario clearly relies on a HW design that provides appropriate
isolation between the programming interfaces.
The two key needs are:
1. Mechanisms to safely delegate a subset of the device MMIO
resources to a client process without over-sharing wider access
(or influence over whole-device activities, such as reset).
2. Mechanisms to allow a client process to do its own iommufd
management w.r.t. its address space, in a way that's isolated
from DMA relating to other clients.
mmap() of VFIO DMABUFs
======================
First, this RFC addresses #1, implementing the proposals in [0] to add
mmap() support to the existing VFIO DMABUF exporter.
This enables a userspace driver to define DMABUF ranges corresponding
to sub-ranges of a BAR, and grant a given client (via a shared fd)
the capability to access (only) those sub-ranges. The VFIO device fds
would be kept private to the primary process. All the client can do
with that fd is map (or iomap via iommufd) that specific subset of
resources, and the impact of bugs/malice is contained.
(We'll follow up on #2 separately, as a related-but-distinct problem.
PASIDs are one way to achieve per-client isolation of DMA; another
could be sharing of a single IOVA space via 'constrained' iommufds.)
Revocation/reclaim
==================
That's useful as-is, but then the lifetime of access granted to a
client needs to be managed well. For example, a protocol between the
primary process and the client can indicate when the client is done,
and when it's safe to reuse the resources elsewhere.
Resources could be released cooperatively, but it's much more robust
to enable the driver to make the resources guaranteed-inaccessible
when it chooses, so that it can re-assign them to other uses in
future.
So, second, I've suggested a PoC/example mechanism for reclaiming
ranges shared with clients: a new DMABUF ioctl, DMA_BUF_IOCTL_REVOKE,
is routed to a DMABUF exporter callback. The VFIO DMABUF exporter's
implementation permanently revokes a DMABUF (notifying importers, and
zapping PTEs for any mappings). This makes the DMABUF defunct and any
client (or third party the client has shared the buffer onto!) cannot
be used to access the BAR ranges, whether via DMABUF import or mmap().
A primary driver process would do this operation when the client's
tenure ends to reclaim "loaned-out" MMIO interfaces, at which point
the interfaces could be safely re-used.
This ioctl is one of several possible approaches to achieve buffer
revocation, but I wanted to demonstrate something here as it's an
important part of the buffer lifecycle in this driver scenario. An
alternative implementation could be some VFIO-specific operation to
search for a DMABUF (by address?) and kill it, but if the server keeps
hold of the DMABUF fd that's already a clean way to locate it later.
BAR mapping access attributes
=============================
Third, inspired by Alex [Mastro] and Jason's comments in [0], and
Mahmoud's work in [1] with the goal of controlling CPU access
attributes for VFIO BAR mappings (e.g. WC) I noticed that once we can
mmap() VFIO DMABUFs representing BAR sub-spans, it's straightforward
to decorate them with access attributes for the VMA.
I've proposed reserving a field in struct
vfio_device_feature_dma_buf's flags to specify an attribute for its
ranges. Although that keeps the (UAPI) struct unchanged, it means all
ranges in a DMABUF share the same attribute. I feel a single
attribute-to-mmap() relation is logical/reasonable. An application
can also create multiple DMABUFs to describe any BAR layout and mix of
attributes.
Tests
=====
I've included an [RFC ONLY] userspace test program which I am _not_
proposing to merge, but am sharing for context. It illustrates &
tests various map/revoke cases, but doesn't use the existing VFIO
selftests and relies on a (tweaked) QEMU EDU function. I'm working on
integrating the scenarios into the existing VFIO selftests.
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...).
(The first two commits are a couple of tiny bugfixes which I can send
separately, should reviewers prefer.)
This series is based on v6.19 but I expect to rebase, at least onto
Leon's recent work [2] ("vfio: Wait for dma-buf invalidation to
complete").
What are people's thoughts? I'll respin to de-RFC and capture
comments, if we think this approach is appropriate.
Thanks,
Matt
References:
[0]: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/
[1]: https://lore.kernel.org/all/20250804104012.87915-1-mngyadam@amazon.de/
[2]: https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a…
Matt Evans (7):
vfio/pci: Ensure VFIO barmap is set up before creating a DMABUF
vfio/pci: Clean up DMABUFs before disabling function
vfio/pci: Support mmap() of a DMABUF
dma-buf: uapi: Mechanism to revoke DMABUFs via ioctl()
vfio/pci: Permanently revoke a DMABUF on request
vfio/pci: Add mmap() attributes to DMABUF feature
[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test
drivers/dma-buf/dma-buf.c | 5 +
drivers/vfio/pci/vfio_pci_core.c | 4 +-
drivers/vfio/pci/vfio_pci_dmabuf.c | 300 ++++++-
include/linux/dma-buf.h | 22 +
include/uapi/linux/dma-buf.h | 1 +
include/uapi/linux/vfio.h | 12 +-
tools/testing/selftests/vfio/Makefile | 1 +
.../vfio/standalone/vfio_dmabuf_mmap_test.c | 822 ++++++++++++++++++
8 files changed, 1153 insertions(+), 14 deletions(-)
create mode 100644 tools/testing/selftests/vfio/standalone/vfio_dmabuf_mmap_test.c
--
2.47.3