Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6269 discussions

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

by Jason Gunthorpe

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

18 hours, 54 minutes

[PATCH v5 0/4] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

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>

19 hours, 52 minutes

Ragdoll en venta Málaga

by Chong Criston

22 hours, 44 minutes

gatitos Ragdoll Sevilla

by Chong Criston

22 hours, 44 minutes

comprar gato Ragdoll Valencia

by Chong Criston

22 hours, 45 minutes

criador Ragdoll Barcelona

by Chong Criston

22 hours, 45 minutes

gatitos Ragdoll en venta Madrid

by Chong Criston

22 hours, 46 minutes

Re: [PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports

by Nicolas Dufresne

Hi Markus, Le mercredi 29 avril 2026 à 19:53 +0000, Markus Fritsche a écrit : > Hi, > > This series proposes a small opt-in API in videobuf2-core that lets V4L2 > drivers populate a dma_resv exclusive write fence on the dmabufs they > export to userspace, signalled when the buffer transitions to > VB2_BUF_STATE_DONE. Two example drivers (hantro, rockchip-rga) opt in > to demonstrate the call shape; the change is no-op for every other > driver. Thanks for attempting again this feat. I see you went for implicit fencing, but in the past we've been recommend to stay away from these and adopt an explicit fencing model. Is this something you have started to think about, have you reviewed past proposal in regard to fences ? > > Why > --- > Modern Wayland compositors and any other userspace consumers that > import V4L2-produced dmabufs and want to do implicit synchronization > the spec-clean way (poll(POLLIN) on the dmabuf fd, or > DMA_BUF_IOCTL_EXPORT_SYNC_FILE for a sync_file) currently get either: > > 1. A stub fence from dma_buf_export_sync_file(), because the dmabuf's > dma_resv has no fences populated. The kernel substitutes > dma_fence_get_stub() which is permanently signalled. The compositor > "successfully" waits on a fence that represents nothing real about > the producer's state. > 2. A poll(POLLIN) on the dmabuf fd that returns immediately for the > same reason — dma_buf_poll_add_cb finds zero fences in the resv, > triggers the wake callback inline, and reports POLLIN ready before > the producer has actually said anything. > > Today this works as a happy accident on most paths because clients > attach buffers after VIDIOC_DQBUF, which the userspace V4L2 contract > guarantees only returns a buffer after the producer is done. So the > implicit "the kernel's stub fence is fine because the buffer is > already complete by the time anyone polls it" assumption has held. There is no accident, just saying. Have you studied also the other side of fences, the one that actually cause problem with Freedreno and Etnaviv ? To me these would be higher priority since they are known to cause "back flash" kind of bugs, specially for compositor that are not expecting GL driver to place implicit fences on imported (v4l2 allocated) buffers. > > But: > > - It's a contract gap. The kernel claims to expose implicit sync; it > does not, for V4L2 producers. > - It paid latency for nothing. Every Wayland frame from a V4L2 > producer pays a DMA_BUF_IOCTL_EXPORT_SYNC_FILE round-trip for a > fence that's stub-signalled. On Mali-class hardware (RK3566 Wayland > chrome video playback), this contributed to compositor stalls. > Removing the wait at the compositor level is a workaround, not a > fix. > - It blocks downstream consumers from doing the right thing. A > Wayland compositor that defensively waits on a sync_file gets a > stub-fence pass-through with no actual gating; if the V4L2 driver > ever has an out-of-band path that releases the buffer before > finishing the write, there is no fence to gate on. Some things don't add up here. I think I want to remind that there is a contract in regard to delivering a fence to userspace. One of the most important aspect of fences is that they must in finit time be signaled, regardless what userspace decided to do next. And for that reason, you shouldn't deliver a fence to userspace if its not armed. In my reading, you are delivering that fence at QBUF(capture) time, just like what Gustavo was trying to do previously. Its even worse if you deliver it to your compositor allowing that compositor to hang forever by not feeding any bitstream. Let's take Hantro driver as an example. The right moment to deliver the fence is either right before we set the DEC bit on the control register, or somewhere before that when you have bitstream, parameters and request queued. At that moment, you are guarantied that the decode will either finish or fail (yes, it can fail, and its extremely common with live stream, or when application calls streamoff, since in v4l2, we cancel work). Prior to that, user may starve the OUTPUT queue (the bitstream) and cause the fence to hold forever. This would break the contract I mention earlier. Though, if you attach the fence at that moment, you will need to design how to signal the fence readiness (rather then the data readiness). One idea would be (with userspace opting-in) to signal the queue at that moment. But then you can't do the memory management operation you would normally do in DQBUF. This of course don't apply to hantro, which has no device cache, but we can't design something in vb2 for the old HW. So we'd need to move memory management somwhere else, maybe buffer_done, though you have to carefully make sure in which context you do that, you can't sleep in an IRQ. There is an obvious benefit of basing your solution on DMA_BUF_IOCTL_EXPORT_SYNC_FILE, once you get there, you'll discover that there is very little room in v4l2_buffer, and that was causing a lot of headache to previous people attempting this. Though, if we look forward, we could also consider this a feature of the media_request. Queuing a request could maybe deliver a fence, assuming few pre-condition that guarantee execution (or failure) are met. We've seen with DW100 recently that its rather easy to convert an existing m2m driver to request. The media API is a much more open canvas to design new mechanism. We could have a really simple ioctl that attach out fences to request, and in a future hook it to our own depedency manager. I'm simply throwing ideas, I could have missed few things in your PoC, let me know. Nicolas > What > ---- > Patch 1 adds: > > - struct dma_fence *release_fence to struct vb2_buffer > - u64 dma_resv_fence_context + atomic64_t dma_resv_fence_seqno + > spinlock_t dma_resv_fence_lock to struct vb2_queue > - vb2_buffer_attach_release_fence(vb) — drivers call this from their > buf_queue callback. Allocates a dma_fence on the queue's fence > context, attaches it as DMA_RESV_USAGE_WRITE on each plane's > dmabuf->resv. No-op for buffers without exported dmabufs. > - vb2_buffer_done() extended to signal+put the fence if attached, > so the producer's completion signal lands in the resv synchronously > with the userspace DQBUF wakeup. > > Patches 2 and 3 add a single call to the helper from hantro_buf_queue > and rga_buf_queue respectively. Both are demonstration drivers; other > vb2 drivers can opt in incrementally with the same one-line change. > > Tested on > --------- > PineTab2 (RK3566 / Mali-G52 panfrost / mainline 6.19.10, this series > backported), playing 1080p30 H.264 in chromium under KDE Plasma 6.6.4 > Wayland. The test harness is the chromium-fourier patch series at > https://github.com/marfrit/fourier — chromium plus a KWin patch > that *previously bypassed* Transaction::watchDmaBuf because the > kernel-side fence was stub-signalled. With this series applied, the > bypass becomes unnecessary; KWin's fence wait completes correctly > because the fence now signals when hantro completes the capture > buffer write. > > End-to-end result before the kernel patch (chromium + Qt 6 patches + > KWin watchDmaBuf bypass): 1080p30 H.264 plays through, ~81% combined > chrome CPU, but the watchDmaBuf bypass weakens KWin's defenses against > misbehaving clients. > > End-to-end result after the kernel patch (chromium + Qt 6 patches + > plain unmodified KWin): 1080p30 H.264 plays through with the same CPU > profile, KWin's watchDmaBuf wait completes within microseconds against > the now-real producer fence, no defenses weakened. > > What's missing in this RFC > -------------------------- > - Other vb2-using drivers don't opt in. Each maintainer should look > at their driver and decide. The hantro + rga patches show the > shape; copying it to other drivers should be straightforward. > - For drivers that have intermediate image-processor stages (e.g. > CSI -> ISP -> user), the fence semantics across stage boundaries > are out of scope here. This series only addresses the producer-to- > userspace edge. > - No selftest. videobuf2 doesn't have a great in-tree selftest harness > for dmabuf flows; the validation is end-to-end at the userspace > consumer level (KWin, in our case). > > Reviews especially welcome on: > > - The decision to make this opt-in per driver vs. automatic for all > vb2-CAPTURE queues. Auto-on would force every driver to be audited; > opt-in is incremental and safer but leaves the contract gap for > drivers nobody touches. > - Whether vb2_buffer_done is the right place to signal vs. an earlier > hook (e.g. immediately after DMA-from-device finishes). For hantro > the two are effectively the same; for drivers with asynchronous > post-processing they may differ. > - The choice of DMA_RESV_USAGE_WRITE — we are emitting the producer's > write completion, so WRITE matches dma-buf documentation, but a > sanity check is welcome. > > Cheers, > Markus > > > Markus Fritsche (3): > media: videobuf2: add dma_resv release-fence helper > media: hantro: attach dma_resv release fence at buf_queue > media: rockchip-rga: attach dma_resv release fence at buf_queue > > .../media/common/videobuf2/videobuf2-core.c | 95 +++++++++++++++++++ > drivers/media/platform/rockchip/rga/rga-buf.c | 10 ++ > .../media/platform/verisilicon/hantro_v4l2.c | 12 +++ > include/media/videobuf2-core.h | 29 ++++++ > 4 files changed, 146 insertions(+)

1 day, 5 hours

Re: [PATCH v3 01/10] file: add callback for creating long-term dmabuf maps

by Christian König

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

1 day, 6 hours

[PATCH v13 0/5] Rust bindings for gem shmem

by Lyude Paul

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

2 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig