Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

21 participants
3588 discussions

[RFC PATCH v8 00/14] coco: guest: Add a shared-granule allocator for host-shared memory

by Aneesh Kumar K.V (Arm)

This series tightens the alignment requirements for buffers that are shared between confidential-computing guests and the host, and adds a common allocator for host-shared memory. When a guest runs with private memory, buffers shared with the hypervisor are not only accessed by the guest. They are also accessed by the host kernel, and the host may manage the corresponding shared/private state at a granularity larger than the guest page size. This matters for CCA systems where the Realm stage-2 mappings managed by the RMM can still operate at 4K granularity, while the non-secure host may manage the IPA state change at a larger page size, for example 64K. In that case, allowing a guest to convert and share only a 4K subrange of a host-managed granule is unsafe. Architectures such as Arm can detect incorrect accesses to Realm physical address space PFNs through GPC faults. However, relying on that as the only line of defence is fragile and can still lead to kernel crashes. The risk is especially visible for shared buffers that are later mmapped into userspace, such as guest_memfd or dma-buf backed allocations. Once userspace can access the mapping, the kernel cannot guarantee that applications will only touch the intended 4K region rather than the whole host page mapped into their address space. Those userspace addresses may also be passed back into the kernel and accessed through the linear map, resulting in a GPC fault. To avoid this, host-shared buffers must satisfy two constraints: - the address must be aligned to the CoCo shared-granule size - the size must be a multiple of that granule size The series adds a common CoCo shared-memory layer for enforcing these constraints. It provides shared-granule geometry and range-validation helpers, byte-oriented private/shared transition helpers, and alloc_cc_shared_pages() with a node-aware variant. The allocator rounds a request to the architecture shared granule, allocates suitably aligned contiguous pages, transitions the complete allocation to shared state, and returns the transitioned size alongside the page. The corresponding free helper restores the complete allocation to private state before returning it to the buddy allocator. If private state cannot be restored safely, the allocation is deliberately leaked rather than returning potentially shared memory for unrelated use. Since a private-to-shared transition may modify memory contents, __GFP_ZERO is applied after the transition. The generic shared-granule size defaults to PAGE_SIZE. For arm64 CCA, the series queries the host IPA state change alignment through the Realm Host Interface, caches it during Realm initialization, and exposes it through the arm64 memory-encryption operations. The common allocator is used for host-shared allocations whose backing is owned by an individual caller: - GIC ITS command queues and tables - dma-direct allocations backed by CMA or the page allocator - backing allocations for the CoCo atomic DMA pools - dma-buf system_cc_shared heap allocations Hyper-V users of set_memory_encrypted() and set_memory_decrypted() are not changed by this series. Those paths are not currently used by the arm64 CCA code path, and therefore are not part of the arm64 CCA IPA state change alignment problem addressed here. NOTE: I have not added explicit MAINTAINERS entries for mm/cc_shared.c and include/linux/cc_shared.h, as I am unsure whether we need a separate section for common CoCo-related files. I will add the entries based on feedback. Changes from v7: https://lore.kernel.org/all/20260921144847.501151-1-aneesh.kumar@kernel.org * Add the following new patches: * "irqchip/gic-v3-its: Preallocate VPE L1 tables" * "mm: Assert CoCo shared allocations may sleep" * "mm: Zero memory during shared memory transitions" * Drop the arm64 RHI and shared granule size patches so that the series can be rebased on top of upstream to enable Shashiko review. Changes from v6: https://lore.kernel.org/all/20260904103452.1197239-1-aneesh.kumar@kernel.org * Add a common allocator and geometry/transition helpers for CoCo host-shared memory. * Convert GIC ITS, dma-direct, atomic DMA pools, and the dma-buf system_cc_shared heap to the common allocator. * Limit dma-buf scatterlist entries to the requested buffer size so rounded backing is not exposed to importers. Changes from v5: https://lore.kernel.org/all/20260706060432.1375570-1-aneesh.kumar@kernel.org * Rebased to latest kernel * Drop patch arm64: realm: Move Realm memory encryption ops to RSI code Changes from v4: https://lore.kernel.org/all/20260427063108.909019-1-aneesh.kumar@kernel.org * Rename the helpers to use CoCo terminology (mem_cc_shared_granule_size() / mem_cc_align_to_shared_granule() instead of mem_decrypt_granule_size() / mem_decrypt_align()). * Use __DMA_ATTR_ALLOC_CC_SHARED to pass CoCo shared allocation requirements down to CMA-based allocation helpers. * Add validation for restricted DMA pools to reject pools that are not aligned to the shared granule size. * Add dma-buf system heap handling for cc-shared buffers. * Split the previous combined DMA/SWIOTLB/ITS change into smaller subsystem patches covering ITS, DMA direct, SWIOTLB, restricted DMA pools, dma-buf system heap, and arm64 Realm support. * Rework arm64 Realm support by moving Realm memory encryption ops into RSI code and exposing the CCA shared granule size through arm64_mem_crypt_ops. Changes from v3: https://lore.kernel.org/all/20260309102625.2315725-1-aneesh.kumar@kernel.org * Fix build error reported by kernel test robot <lkp(a)intel.com> Changes from v2: https://lore.kernel.org/all/20251221160920.297689-1-aneesh.kumar@kernel.org * Rebase to latest kernel * Consider swiotlb always decrypted and don't align when allocating from swiotlb. Changes from v1: * Rename the helper to mem_encrypt_align * Improve the commit message * Handle DMA allocations from contiguous memory * Handle DMA allocations from the pool * swiotlb is still considered unencrypted. Support for an encrypted swiotlb pool is left as TODO and is independent of this series. Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Baoquan He <baoquan.he(a)linux.dev> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Pratyush Yadav <pratyush(a)kernel.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Joerg Roedel (AMD) <joro(a)8bytes.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Steven Price <steven.price(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Thomas Gleixner <tglx(a)kernel.org> Cc: Will Deacon <will(a)kernel.org> Cc: Russell King <linux(a)armlinux.org.uk> Cc: Benjamin Gaignard <benjamin.gaignard(a)collabora.com> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: John Stultz <jstultz(a)google.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Radu Rendec <radu(a)rendec.net> Cc: "T.J. Mercier" <tjmercier(a)google.com> Cc: Madhavan Srinivasan <maddy(a)linux.ibm.com> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Christophe Leroy (CS GROUP) <chleroy(a)kernel.org> Cc: Ritesh Harjani (IBM) <ritesh.list(a)gmail.com> Cc: Shrikanth Hegde <sshegde(a)linux.ibm.com> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: x86(a)kernel.org Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Kiryl Shutsemau <kas(a)kernel.org> Cc: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Haiyang Zhang <haiyangz(a)microsoft.com> Cc: Wei Liu <wei.liu(a)kernel.org> Cc: Dexuan Cui <decui(a)microsoft.com> Cc: Long Li <longli(a)microsoft.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: dri-devel(a)lists.freedesktop.org Cc: iommu(a)lists.linux.dev Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: linux-mm(a)kvack.org Aneesh Kumar K.V (Arm) (14): mm: Add an allocator for CoCo shared memory mm: Zero memory during shared memory transitions irqchip/gic-v3-its: Resolve the default NUMA node explicitly irqchip/gic-v3-its: Allocate shared tables using CoCo shared memory allocator dma-contiguous: Derive shared alignment from DMA attributes dma-pool: Allocate CoCo atomic pools using CoCo shared memory allocator dma-direct: Align CoCo shared DMA allocations to the shared granule size swiotlb: Align shared IO TLB pools to the shared granule size swiotlb: Reject misaligned restricted DMA pools for CoCo guests dma-buf: system_heap: Limit scatterlist entries to the buffer size dma-buf: system_heap: Allocate shared buffers using CoCo shared memory allocator swiotlb: Make rounded shared pool capacity allocatable mm: Assert CoCo shared allocations may sleep irqchip/gic-v3-its: Preallocate VPE L1 tables arch/arm/mm/dma-mapping.c | 5 +- arch/arm64/mm/pageattr.c | 3 + arch/powerpc/platforms/pseries/svm.c | 2 + arch/s390/mm/init.c | 3 + arch/x86/coco/tdx/tdx.c | 3 + arch/x86/hyperv/hv_init.c | 6 +- arch/x86/hyperv/ivm.c | 4 + arch/x86/kernel/kvmclock.c | 6 +- arch/x86/mm/mem_encrypt_amd.c | 4 + drivers/dma-buf/heaps/system_heap.c | 128 +++++----- drivers/hv/connection.c | 41 ++-- drivers/hv/hv.c | 11 +- drivers/hv/hv_common.c | 2 - drivers/iommu/dma-iommu.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 153 +++++++++--- drivers/irqchip/irq-gic-v3.c | 4 +- drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c | 3 + include/linux/cc_shared.h | 39 +++ include/linux/dma-map-ops.h | 9 +- include/linux/irqchip/arm-gic-v3.h | 3 +- kernel/dma/contiguous.c | 41 +++- kernel/dma/direct.c | 73 ++++-- kernel/dma/ops_helpers.c | 2 +- kernel/dma/pool.c | 25 +- kernel/dma/swiotlb.c | 80 ++++-- kernel/kexec_file.c | 3 +- mm/Makefile | 1 + mm/cc_shared.c | 232 ++++++++++++++++++ 28 files changed, 682 insertions(+), 206 deletions(-) create mode 100644 include/linux/cc_shared.h create mode 100644 mm/cc_shared.c base-commit: 704340f1cd0dcef829eb62f5b48ae95a2ce17bdf -- 2.43.0

1 hour, 15 minutes

Re: [RFC PATCH v7 02/13] mm: Add an allocator for CoCo shared memory

by Jason Gunthorpe

On Wed, Sep 23, 2026 at 09:28:54AM -0700, Kameron Carr wrote: > On 9/23/2026 8:21 AM, Jason Gunthorpe wrote: > > On Wed, Sep 23, 2026 at 08:28:57PM +0530, Aneesh Kumar K.V wrote: > > > >> I'm also considering requiring the address passed to cc_make_shared() to > >> be in the linear map. This is currently required by both TDX and CCA, > >> while AMD SNP appears to support vmalloc addresses. The only user of > >> that vmalloc support is Hyper-V VMBus GPADL setup > >> (vmbus_establish_gpadl()). How should the generic CoCo shared-memory > >> allocator handle this? > > > > vmbus_establish_gpadl() is the the same wrong abstraction as the arch > > code. Get rid of it and use vmbus_establish_gpadl_caller_decrypted(): > > > > pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE); > > if (!pdata->recv_buf) { > > ret = -ENOMEM; > > goto fail_free_ring; > > } > > > > ret = vmbus_establish_gpadl(channel, pdata->recv_buf, > > RECV_BUFFER_SIZE, &pdata->recv_gpadl); > > > > > > So you made an allocator that returns folios, now you just need to > > use that allocator to implement a kvzalloc wrapper. ARM can call vmap > > on decrypted memory with pgprot_decrypted(), right? > > > > Or maybe this can use vmbus_alloc_buffer(), it already does it. > > Michael Kelley recently proposed [1] moving all ring buffer allocations > to use vmbus_alloc_buffer(). If we move forward with this, it should > remove the dependency on vmalloc support. Even better vmbus_alloc_buffer() can use the new allocator API directly so it doesn't need to open code the set_memory_decrypted arch call. Lets do it! Jaon

17 hours, 57 minutes

Re: [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request

by Jason Gunthorpe

On Tue, Sep 22, 2026 at 03:31:07PM -0700, Alex Mastro wrote: > So I empathize with Matt's contention that the _existing_ behavior that the > priv->revoked flag represents is actually "temporarily revoked": the importer > can use the same dma-buf again, later, without having to re-import > it! mlx5 isn't a revoking importer, it is move capable. So the above sequence isn't a revoke, it is a move with an unmapped placement for a while. This is why "temporarily revoked" is a confusing phrase. The API is such that move and revoke importers can co-exist like this but they experiance a different version of things.. We probably should not have made it have this move compatible restoration and had things more consistent. User space can't know if the importer is move capable or not so it has to assume revoke and it has to go and unmap things before resetting/etc. > This series doesn't intend to change the behavior of either. Is the confusion > about whether the current behavior is intentional and/or desirable? If the > answer to both is "no", then IMO this series paves the way nicely towards making > PERM_REVOKED the only supported semantic later. Right, I think the only concern is language. Jason

18 hours, 14 minutes

[RFC PATCH v7 00/13] coco: guest: Add a shared-granule allocator for host-shared memory

by Aneesh Kumar K.V (Arm)

Hi, This series tightens the alignment requirements for buffers that are shared between confidential-computing guests and the host, and adds a common allocator for host-shared memory. When a guest runs with private memory, buffers shared with the hypervisor are not only accessed by the guest. They are also accessed by the host kernel, and the host may manage the corresponding shared/private state at a granularity larger than the guest page size. This matters for CCA systems where the Realm stage-2 mappings managed by the RMM can still operate at 4K granularity, while the non-secure host may manage the IPA state change at a larger page size, for example 64K. In that case, allowing a guest to convert and share only a 4K subrange of a host-managed granule is unsafe. Architectures such as Arm can detect incorrect accesses to Realm physical address space PFNs through GPC faults. However, relying on that as the only line of defence is fragile and can still lead to kernel crashes. The risk is especially visible for shared buffers that are later mmapped into userspace, such as guest_memfd or dma-buf backed allocations. Once userspace can access the mapping, the kernel cannot guarantee that applications will only touch the intended 4K region rather than the whole host page mapped into their address space. Those userspace addresses may also be passed back into the kernel and accessed through the linear map, resulting in a GPC fault. To avoid this, host-shared buffers must satisfy two constraints: - the address must be aligned to the CoCo shared-granule size - the size must be a multiple of that granule size The series adds a common CoCo shared-memory layer for enforcing these constraints. It provides shared-granule geometry and range-validation helpers, byte-oriented private/shared transition helpers, and alloc_cc_shared_pages() with a node-aware variant. The allocator rounds a request to the architecture shared granule, allocates suitably aligned contiguous pages, transitions the complete allocation to shared state, and returns the transitioned size alongside the page. The corresponding free helper restores the complete allocation to private state before returning it to the buddy allocator. If private state cannot be restored safely, the allocation is deliberately leaked rather than returning potentially shared memory for unrelated use. Since a private-to-shared transition may modify memory contents, __GFP_ZERO is applied after the transition. The generic shared-granule size defaults to PAGE_SIZE. For arm64 CCA, the series queries the host IPA state change alignment through the Realm Host Interface, caches it during Realm initialization, and exposes it through the arm64 memory-encryption operations. The common allocator is used for host-shared allocations whose backing is owned by an individual caller: - GIC ITS command queues and tables - dma-direct allocations backed by CMA or the page allocator - backing allocations for the CoCo atomic DMA pools - dma-buf system_cc_shared heap allocations Hyper-V users of set_memory_encrypted() and set_memory_decrypted() are not changed by this series. Those paths are not currently used by the arm64 CCA code path, and therefore are not part of the arm64 CCA IPA state change alignment problem addressed here. NOTE: I have not added explicit MAINTAINERS entries for mm/cc_shared.c and include/linux/cc_shared.h, as I am unsure whether we need a separate section for common CoCo-related files. I will add the entries based on feedback. The series is based on: - https://lore.kernel.org/all/20260921053807.354802-1-aneesh.kumar@kernel.org Changes from v6: https://lore.kernel.org/all/20260904103452.1197239-1-aneesh.kumar@kernel.org * Add a common allocator and geometry/transition helpers for CoCo host-shared memory. * Convert GIC ITS, dma-direct, atomic DMA pools, and the dma-buf system_cc_shared heap to the common allocator. * Limit dma-buf scatterlist entries to the requested buffer size so rounded backing is not exposed to importers. Changes from v5: https://lore.kernel.org/all/20260706060432.1375570-1-aneesh.kumar@kernel.org * Rebased to latest kernel * Drop patch arm64: realm: Move Realm memory encryption ops to RSI code Changes from v4: https://lore.kernel.org/all/20260427063108.909019-1-aneesh.kumar@kernel.org * Rename the helpers to use CoCo terminology (mem_cc_shared_granule_size() / mem_cc_align_to_shared_granule() instead of mem_decrypt_granule_size() / mem_decrypt_align()). * Use __DMA_ATTR_ALLOC_CC_SHARED to pass CoCo shared allocation requirements down to CMA-based allocation helpers. * Add validation for restricted DMA pools to reject pools that are not aligned to the shared granule size. * Add dma-buf system heap handling for cc-shared buffers. * Split the previous combined DMA/SWIOTLB/ITS change into smaller subsystem patches covering ITS, DMA direct, SWIOTLB, restricted DMA pools, dma-buf system heap, and arm64 Realm support. * Rework arm64 Realm support by moving Realm memory encryption ops into RSI code and exposing the CCA shared granule size through arm64_mem_crypt_ops. Changes from v3: https://lore.kernel.org/all/20260309102625.2315725-1-aneesh.kumar@kernel.org * Fix build error reported by kernel test robot <lkp(a)intel.com> Changes from v2: https://lore.kernel.org/all/20251221160920.297689-1-aneesh.kumar@kernel.org * Rebase to latest kernel * Consider swiotlb always decrypted and don't align when allocating from swiotlb. Changes from v1: * Rename the helper to mem_encrypt_align * Improve the commit message * Handle DMA allocations from contiguous memory * Handle DMA allocations from the pool * swiotlb is still considered unencrypted. Support for an encrypted swiotlb pool is left as TODO and is independent of this series. Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: christian.koenig(a)amd.com Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Joerg Roedel (AMD) <joro(a)8bytes.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Steven Price <steven.price(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Thomas Gleixner <tglx(a)kernel.org> Cc: Will Deacon <will(a)kernel.org> Cc: dri-devel(a)lists.freedesktop.org Cc: iommu(a)lists.linux.dev Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: linux-mm(a)kvack.org Aneesh Kumar K.V (Arm) (13): arm64: realm: Add RHI helper to query IPA state change alignment mm: Add an allocator for CoCo shared memory arm64: realm: Expose the CCA shared granule size through mem_encrypt ops irqchip/gic-v3-its: Resolve the default NUMA node explicitly irqchip/gic-v3-its: Allocate shared tables using CoCo shared memory allocator dma-contiguous: Accept an explicit minimum alignment dma-pool: Allocate CoCo atomic pools using CoCo shared memory allocator dma-direct: Align CoCo shared DMA allocations to the shared granule size swiotlb: Align shared IO TLB pools to the shared granule size swiotlb: Reject misaligned restricted DMA pools for CoCo guests dma-buf: system_heap: Limit scatterlist entries to the buffer size dma-buf: system_heap: Allocate shared buffers using CoCo shared memory allocator swiotlb: Make rounded shared pool capacity allocatable MAINTAINERS | 1 + arch/arm/mm/dma-mapping.c | 5 +- arch/arm64/include/asm/mem_encrypt.h | 1 + arch/arm64/mm/mem_encrypt.c | 13 +- drivers/dma-buf/heaps/system_heap.c | 126 +++++++++----------- drivers/firmware/arm_rmm/rsi.c | 58 +++++++++ drivers/iommu/dma-iommu.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 43 +++---- include/linux/arm-rsi-cmds.h | 10 ++ include/linux/arm-smccc-rhi.h | 25 ++++ include/linux/arm-smccc-rsi.h | 7 ++ include/linux/cc_shared.h | 39 ++++++ include/linux/dma-map-ops.h | 10 +- kernel/dma/contiguous.c | 33 +++-- kernel/dma/direct.c | 55 +++++++-- kernel/dma/ops_helpers.c | 2 +- kernel/dma/pool.c | 23 +++- kernel/dma/swiotlb.c | 81 +++++++++---- kernel/kexec_file.c | 3 +- mm/Makefile | 1 + mm/cc_shared.c | 172 +++++++++++++++++++++++++++ 21 files changed, 552 insertions(+), 158 deletions(-) create mode 100644 include/linux/arm-smccc-rhi.h create mode 100644 include/linux/cc_shared.h create mode 100644 mm/cc_shared.c -- 2.43.0

19 hours, 59 minutes

Re: [RFC PATCH v1 1/2] dma-buf: keep DMABUF_DEBUG off by default

by Christian König

On 9/23/26 09:42, Jianfeng Liu wrote: > [Sie erhalten nicht häufig E-Mails von liujianfeng1994(a)gmail.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] > > Commit 143755bdabaa9 ("dma-buf: Make DMABUF_DEBUG default to y on > DEBUG_KERNEL kernels") fixed a dangling reference in the DMABUF_DEBUG > default, which had the side effect of enabling the option (and with it > the page-stripping sg_table wrapper handed to importers) on every > kernel with DEBUG_KERNEL=y - i.e. virtually every distro kernel. > > drm/msm is broken by this: it maps imported dma-bufs into the GPU's > own pagetables with iommu_map_sgtable(), which needs the struct page > of the attachment sg_table, and it fills the GEM object's page array > through drm_prime_sg_to_page_array(). With the debug wrapper in > place both silently produce garbage (the wrapper zeroes sg->length, Interesting point, we should probably change that. > so the page iterator yields nothing and an uninitialized array is > kept). The VM_BIND map job then fails asynchronously after userspace > has already enqueued GPU work referencing the mapping, which shows up > as an arm-smmu translation fault from UCHE, e.g.: > > gpu fault: ttbr0=000000088a889000 iova=000000010741c000 dir=READ > type=TRANSLATION source=UCHE > > This breaks hardware video decode (clapper, chromium) on Adreno > systems; bisected on a Snapdragon laptop as v7.3-rc3 good, > v7.3-rc4 bad, culprit 143755bdabaa9. > > Revert the default until importers that legitimately need to build > phys-based mappings have been converted. Well that won't work like this, pointing those things out is exactly what DMABUF_DEBUG is made for. What MSM is doing here is not allowed at all and can break badly. We gave drivers 5 years to get that fixed and I'm now pushing for completely deprecating that hack. See patch 84335675f2223cbd25d0de7d38ecc7d40b95bd4a: Author: Simona Vetter <simona.vetter(a)ffwll.ch> Date: Fri Jan 15 17:47:39 2021 +0100 dma-buf: Add debug option When MSM needs the struct page then it must import a shmemfd and not a DMA-buf. What we could do is to either fix MSM or mark it as broken. Regards, Christian. > > Fixes: 143755bdabaa9 ("dma-buf: Make DMABUF_DEBUG default to y on DEBUG_KERNEL kernels") > Signed-off-by: Jianfeng Liu <liujianfeng1994(a)gmail.com> > --- > > drivers/dma-buf/Kconfig | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index e4f078a326a41..b3c581ef4c987 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -43,7 +43,14 @@ config UDMABUF > config DMABUF_DEBUG > bool "DMA-BUF debug checks" > depends on DMA_SHARED_BUFFER > - default y if DEBUG_KERNEL > + # NOTE: keep this default n. The page-stripping sg_table wrapper that > + # this option installs for importers breaks drivers that build a > + # second-stage IOMMU mapping (phys -> iova) from the attachment sg_table > + # and therefore still need the struct page, e.g. drm/msm with its > + # per-process GPU pagetables. Until those importers are fixed, making > + # this default y breaks hardware video decode and GPU workloads out of > + # the box on affected systems. > + default n > help > This option enables additional checks for DMA-BUF importers and > exporters. Specifically it validates that importers do not peek at the > -- > 2.47.3 >

1 day, 3 hours

Re: [PATCH v2] dma-fence: deliver set_deadline callback even if fence is already signaled

by Christian König

On 9/22/26 18:57, Jeffrey Boody wrote: > The set_deadline callback is currently skipped if the fence has already > been signaled. This prevents GPU drivers from performing power > management adjustments when the deadline hint arrives after fence > completion. > > In triple-buffered rendering, a staged frame may be completed well > ahead of the vblank deadline. When a display driver delivers the > deadline hint, the fence has already been signaled and the callback is > silently dropped. This leaves the GPU driver unable to evaluate the > headroom between the fence signal time and the vblank deadline, and > therefore unable to reduce GPU frequency when the target headroom is > exceeded. > > Remove the dma_fence_is_signaled() guard from dma_fence_set_deadline() > so that the callback is invoked unconditionally when ops->set_deadline > is present. Implementations of set_deadline must already tolerate > concurrent and repeated calls; handling a post-signal invocation > requires no additional locking. The fence signaler can compare the fence > signal time against the supplied deadline to determine whether frequency > scaling is warranted. Sorry but I have to clearly reject that patch. No callback whatsoever is allowed to be used after the fence has signaled or otherwise we break module unloading for the originator of the fence. So that approach you want to have here simply doesn't work at all. Regards, Christian. > > Signed-off-by: Jeffrey Boody <jeffrey.boody(a)oss.qualcomm.com> > --- > Signed-off-by: Jeff Boody <jeffrey.boody(a)oss.qualcomm.com> > --- > drivers/dma-buf/dma-fence.c | 22 ++++++++++++++++++++-- > drivers/gpu/drm/msm/msm_fence.c | 3 +++ > include/linux/dma-fence.h | 11 ++++++++++- > 3 files changed, 33 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index bd58688b81a7..ebc7c5ca6f69 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -999,8 +999,19 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout); > * Multiple deadlines may be set on a given fence, even in parallel. See the > * documentation for &dma_fence_ops.set_deadline. > * > + * The deadline hint may also be delivered *after* the fence has already been > + * signaled. This is intentional and supports the case where a fence signaler > + * aware of a periodic deadline (e.g. vblank) and the fence's signal time can > + * evaluate the headroom between the two. In triple-buffered rendering, for > + * example, a staged frame that is completed well ahead of the vblank deadline > + * represents excess headroom; delivering the deadline hint post-signal allows > + * the fence signaler to consider reducing frequency for subsequent workloads, > + * rather than holding an unnecessarily high frequency. Implementations > + * of &dma_fence_ops.set_deadline must therefore tolerate invocation on > + * already-signaled fences. > + * > * The deadline hint is just that, a hint. The driver that created the fence > - * may react by increasing frequency, making different scheduling choices, etc. > + * may react by changing frequency, making different scheduling choices, etc. > * Or doing nothing at all. > */ > > @@ -1016,6 +1027,13 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout); > * to aid in power management decisions, such as boosting GPU frequency > * if a periodic vblank deadline is approaching but the fence is not > * yet signaled.. > + * > + * This function may also be called after the fence has already been > + * signaled. In that case the fence signaler can compare the fence's signal > + * time against the deadline to determine the available headroom. If the > + * fence was signaled significantly ahead of the deadline, the fence > + * signaler may choose to reduce frequency for subsequent workloads to > + * avoid unnecessarily high power consumption. > */ > void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) > { > @@ -1023,7 +1041,7 @@ void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) > > rcu_read_lock(); > ops = rcu_dereference(fence->ops); > - if (ops && ops->set_deadline && !dma_fence_is_signaled(fence)) > + if (ops && ops->set_deadline) > ops->set_deadline(fence, deadline); > rcu_read_unlock(); > } > diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c > index 3dca8e09c192..3c5de96d4092 100644 > --- a/drivers/gpu/drm/msm/msm_fence.c > +++ b/drivers/gpu/drm/msm/msm_fence.c > @@ -136,6 +136,9 @@ static void msm_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) > unsigned long flags; > ktime_t now; > > + if (dma_fence_is_signaled(fence)) > + return; > + > spin_lock_irqsave(&fctx->spinlock, flags); > now = ktime_get(); > > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index ffa99b930843..839ef2e5dad9 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -264,7 +264,16 @@ struct dma_fence_ops { > * an upcoming deadline, such as vblank, by which point the waiter > * would prefer the fence to be signaled by. This is intended to > * give feedback to the fence signaler to aid in power management > - * decisions, such as boosting GPU frequency. > + * decisions, such as boosting GPU frequency if the deadline has > + * not yet been met, or reducing GPU frequency if the fence was > + * signaled significantly ahead of the deadline. > + * > + * This callback may be invoked even after the fence has been > + * signaled. In this case, the signaler may use the deadline and > + * the fence's signal time to evaluate whether the GPU frequency > + * should be adjusted for future workloads. Implementations must > + * therefore be prepared to handle calls on already-signaled fences > + * without error. > * > * This is called without &dma_fence.lock held, it can be called > * multiple times and from any context. Locking is up to the callee > > --- > base-commit: f0100363d8c374bd8e9ea7c9ba02744f0b802ca4 > change-id: 20260917-dma-fence-set-deadline-a778746e9abd > > Best regards, > -- > Jeff Boody <jeffrey.boody(a)oss.qualcomm.com> >

1 day, 3 hours

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

by Christoph Hellwig

On Tue, Sep 22, 2026 at 02:37:08PM +0100, Pavel Begunkov wrote: >> Sashiko had a few comments, which I think are correct - if we use >> dma_map_sg to map the data, we need to use the sync_sg APIs to >> transfer ownership. That only matters on non-coherent architectures >> with MMU, but we need to get it right. > > I've seen that and fixed everything locally that should be fixed, > apart from the sync. I wonder what we can do about that? I can > somehow replace it with the sg variant for now, but sync'ing the > entire possibly multi-GB mapping for, let's say, a 512B I/O, sounds > not wise. If we'd want to fix this for real we'd need to add an offset to the sync by sg methods. Or move away from scatterlists in dma-buf, given that they are a horrible API. All of these are bigger projects, though. So for now I think you'd want to do the sync all, and have the people who run high-performance io_uring code on non-coherent platforms suffer. > And I can think of another place that does mix sync_single > with sgs. Which one?

1 day, 6 hours

Re: [PATCH v6 04/13] block: introduce dma map backed bio type

by Christoph Hellwig

On Tue, Sep 22, 2026 at 02:54:25PM +0100, Pavel Begunkov wrote: >> >> Can you please expland on the splitting considerations a bit? Preferably >> both in a comment for the details, and in the commit log for how we >> arrived at them and why they are fine for now? > > I'll add something to the commit log, but not sure which specific > details in comments you mean. Do you want me to expand the comment > above limiting the number of segments? Maybe I should add there that > it's stricter than necessary and might cause more splitting than > necessary? This one: Yes, explain why we apply a relatively arbitrary limit not fully exploiting the hardware capabilities, and why we thing that is okay.

1 day, 6 hours

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

by Christoph Hellwig

On Mon, Sep 21, 2026 at 02:38:50PM +0100, Pavel Begunkov wrote: > Enable BIO_DMABUF_MAP backed requests. On registration we map the This is now REQ_DMABUF. Sashiko had a few comments, which I think are correct - if we use dma_map_sg to map the data, we need to use the sync_sg APIs to transfer ownership. That only matters on non-coherent architectures with MMU, but we need to get it right. And the reset deadlock also looks plausible.

1 day, 22 hours

Re: [PATCH v6 04/13] block: introduce dma map backed bio type

by Christoph Hellwig

On Mon, Sep 21, 2026 at 02:38:48PM +0100, Pavel Begunkov wrote: > Premapped buffers don't require a generic bio_vec since these have > already been dma mapped. Repurpose the bi_io_vec space to strore dmabuf s/strore/store/ Can you please expland on the splitting considerations a bit? Preferably both in a comment for the details, and in the commit log for how we arrived at them and why they are fine for now? Otherwise looks good.

1 day, 22 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig