On Thu, Apr 30, 2026 at 05:47:49PM +0100, Matt Evans wrote:
> > On Thu, Apr 16, 2026 at 06:17:46AM -0700, Matt Evans wrote:
> > > +int vfio_pci_core_mmap_prep_dmabuf(struct vfio_pci_core_device *vdev,
> > > + struct vm_area_struct *vma,
> > > + u64 phys_start, u64 req_len,
> > > + unsigned int res_index)
> > > +{
> > > + struct vfio_pci_dma_buf *priv;
> > > + const unsigned int nr_ranges = 1;
> > > + int ret;
> > > +
> > > + priv = kzalloc_obj(*priv);
> > > + if (!priv)
> > > + return -ENOMEM;
> > > +
> > > + priv->phys_vec = kzalloc_obj(*priv->phys_vec);
> > > + if (!priv->phys_vec) {
> > > + ret = -ENOMEM;
> > > + goto err_free_priv;
> > > + }
> > > +
> > > + /*
> > > + * The mmap() request's vma->vm_offs might be non-zero, but
> > > + * the DMABUF is created from _offset zero_ of the BAR. The
> > > + * portion between zero and the vm_offs is inaccessible
> > > + * through this VMA, but this approach keeps the
> > > + * /proc/<pid>/maps offset somewhat consistent with the
> > > + * pre-DMABUF code. Size includes the offset portion.
> >
> > I'm not sure I understand this comment?
> >
> > For the old path vm_pgoff for byte 0 of the bar starts at some large
> > offset
> >
> > For the new path vm_pgoff for byte 0 of the first range starts at 0
>
> Glad you asked. :)
>
> This is trying to achieve keeping /proc/<pid>/maps (or similar) somewhat
> as informative as pre-DMABUF BAR mmap, in terms of keeping the VMA
> vm_offs column useful. Before this patch, say you mmap() two slices A
> and B of the same BAR:
>
> struct vfio_region_info bar_region;
>
> vm_a = mmap(0, 0x1000, ..., device_fd, bar_region.offset + 0);
> vm_b = mmap(0, 0x1000, ..., device_fd, bar_region.offset + 0x4000);
>
> ...you'd see something like this in /proc/blah/maps:
>
> fffff4000000-fffff4001000 rw-s 10000000000 00:07 148 /dev/vfio/devices/vfio0
> fffff5000000-fffff5001000 rw-s 10000004000 00:07 148 /dev/vfio/devices/vfio0
> then the VMA's vm_offs would need to be thunked back down to 0 (since
> the fault handler then treats vm_b + 0 as the first byte of the DMABUF).
> That works/adds up, but then the vm_offs of both VMAs A & B both have
> offset 0, and it's harder to differentiate in /proc/blah/maps.
Yes, and that would be correct.
The VMA output of lspci should show the exact pgoff passed to mmap and
nothing else. Do not mangle it for "debugging".
pgoff is not to be used to show random internal FD details..
> We could possibly stash the original offset somewhere and then render it
> in the name string, but the name's already about the max size and using
> the existing vm_offs column is nicer IMO, doesn't need a new field, etc.
> I need to work on this comment then! What this is trying to say is that
> the DMABUF is made artificially larger than the part that is visible
> through the VMA.
Yuk, that's another reason not to do this.
Jason
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 is now easy too with the
reworks we got in 7.1-r1.
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 v5:
- Rebase on 7.1-rc1
- Add a patch to enable the heaps in arm64 defconfig
- Link to v4: https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-0-e18fda5044…
Changes in v4:
- Fix compilation failure
- Rework to take into account OF_RESERVED_MEM
- Fix regression making the default CMA area disappear if not created
through the DT
- Added some documentation and comments
- Link to v3: https://lore.kernel.org/r/20260303-dma-buf-heaps-as-modules-v3-0-24344812c7…
Changes in v3:
- Squashed cma_get_name and cma_alloc/release patches
- Fixed typo in Export dev_get_cma_area commit title
- Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM
- Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06…
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 (4):
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
arm64: defconfig: Enable dma-buf heaps
arch/arm64/configs/defconfig | 3 +++
drivers/dma-buf/dma-heap.c | 1 +
drivers/dma-buf/heaps/Kconfig | 4 ++--
drivers/dma-buf/heaps/cma_heap.c | 3 +++
drivers/dma-buf/heaps/system_heap.c | 5 +++++
5 files changed, 14 insertions(+), 2 deletions(-)
---
base-commit: 5e9b7d093f3f77cb0af4409559e3d139babfb443
change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a
Best regards,
--
Maxime Ripard <mripard(a)kernel.org>
On 4/29/26 17:25, Pavel Begunkov wrote:
> Introduce a new file callback that allows creating long-term dma
> mapping. All necessary information together with a dmabuf will be passed
> in the second argument of type struct io_dmabuf_token, which will be
> defined in following patches.
Well first of all the naming is probably not the best. Maybe rather call that dma-buf attachment or context or mappping.
Then the patch should probably define the full interface and not just add the callback here and then the structure in a follow up patch.
Regards,
Christian.
>
> Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com>
> ---
> include/linux/fs.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b5b01bb22d12..c5558aab4628 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1920,6 +1920,7 @@ struct dir_context {
>
> struct io_uring_cmd;
> struct offset_ctx;
> +struct io_dmabuf_token;
>
> typedef unsigned int __bitwise fop_flags_t;
>
> @@ -1967,6 +1968,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 (*create_dmabuf_token)(struct file *, struct io_dmabuf_token *);
> } __randomize_layout;
>
> /* Supports async buffered reads */
Most of this patch series has already been pushed upstream, this is just
the second half of the patch series that has not been pushed yet + some
additional changes which were required to implement changes requested by
the mailing list. This patch series is originally from Asahi, previously
posted by Daniel Almeida.
The previous version of the patch series can be found here:
https://patchwork.freedesktop.org/series/164580/
Branch with patches applied available here
sure this builds:
https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem
This patch series applies on top of drm-rust-next
Lyude Paul (5):
rust: drm: gem: s/device::Device/Device/ for shmem.rs
drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked()
rust: drm: gem/shmem: Add DmaResvGuard helper
rust: drm: gem: Introduce shmem::SGTable
rust: drm: gem: Add vmap functions to shmem bindings
drivers/gpu/drm/drm_gem_shmem_helper.c | 32 +-
include/drm/drm_gem_shmem_helper.h | 1 +
rust/kernel/drm/gem/shmem.rs | 602 ++++++++++++++++++++++++-
3 files changed, 614 insertions(+), 21 deletions(-)
base-commit: d9a6809478f9815b6455a327aa001737ac7b2c09
--
2.54.0