Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

19 participants
6285 discussions

Re: [PATCH v5 2/2] dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory

by Jason Gunthorpe

On Wed, Mar 25, 2026 at 08:23:52PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Add a new "system_cc_shared" dma-buf heap to allow userspace to > allocate shared (decrypted) memory for confidential computing (CoCo) > VMs. > > On CoCo VMs, guest memory is private by default. The hardware uses an > encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on > Intel TDX) to control whether a given memory access is private or > shared. The kernel's direct map is set up as private, > so pages returned by alloc_pages() are private in the direct map > by default. To make this memory usable for devices that do not support > DMA to private memory (no TDISP support), it has to be explicitly > shared. A couple of things are needed to properly handle > shared memory for the dma-buf use case: > > - set_memory_decrypted() on the direct map after allocation: > Besides clearing the encryption bit in the direct map PTEs, this > also notifies the hypervisor about the page state change. On free, > the inverse set_memory_encrypted() must be called before returning > pages to the allocator. If re-encryption fails, pages > are intentionally leaked to prevent shared memory from being > reused as private. > > - pgprot_decrypted() for userspace and kernel virtual mappings: > Any new mapping of the shared pages, be it to userspace via > mmap or to kernel vmalloc space via vmap, creates PTEs independent > of the direct map. These must also have the encryption bit cleared, > otherwise accesses through them would see encrypted (garbage) data. > > - DMA_ATTR_CC_SHARED for DMA mapping: > Since the pages are already shared, the DMA API needs to be > informed via DMA_ATTR_CC_SHARED so it can map them correctly > as unencrypted for device access. > > On non-CoCo VMs, the system_cc_shared heap is not registered > to prevent misuse by userspace that does not understand > the security implications of explicitly shared memory. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v4->v5: > - bools renamed: s/decrypted/cc_decrypted/ > - other renames: s/decrypted/decrypted/ - this included name of the heap > v2->v3: > - removed couple of leftovers from headers > v1->v2: > - fixed build errors on s390 by including mem_encrypt.h > - converted system heap flag implementation to a separate heap > --- > drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- > 1 file changed, 98 insertions(+), 5 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason

1 week, 2 days

Re: [PATCH v5 1/2] dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory

by Jason Gunthorpe

On Wed, Mar 25, 2026 at 08:23:51PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Current CC designs don't place a vIOMMU in front of untrusted devices. > Instead, the DMA API forces all untrusted device DMA through swiotlb > bounce buffers (is_swiotlb_force_bounce()) which copies data into > shared memory on behalf of the device. > > When a caller has already arranged for the memory to be shared > via set_memory_decrypted(), the DMA API needs to know so it can map > directly using the unencrypted physical address rather than bounce > buffering. Following the pattern of DMA_ATTR_MMIO, add > DMA_ATTR_CC_SHARED for this purpose. Like the MMIO case, only the > caller knows what kind of memory it has and must inform the DMA API > for it to work correctly. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v4->v5: > - rebased on top od dma-mapping-for-next > - s/decrypted/shared/ > v3->v4: > - added some sanity checks to dma_map_phys and dma_unmap_phys > - enhanced documentation of DMA_ATTR_CC_DECRYPTED attr > v1->v2: > - rebased on top of recent dma-mapping-fixes > --- > include/linux/dma-mapping.h | 10 ++++++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/direct.h | 14 +++++++++++--- > kernel/dma/mapping.c | 13 +++++++++++-- > 4 files changed, 34 insertions(+), 6 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason

1 week, 3 days

Re: [PATCH] dma-fence: Move signalling tracepoint to before ops detach

by Christian König

On 3/30/26 15:36, Tvrtko Ursulin wrote: > Move the signalling tracepoint to before fence->ops are reset otherwise > tracepoint will dereference a null pointer. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") > Cc: Christian König <christian.koenig(a)amd.com> > Cc: Philipp Stanner <phasta(a)kernel.org> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: linux-media(a)vger.kernel.org > Cc: linaro-mm-sig(a)lists.linaro.org Good catch. I just silently assumed that the fence is not signaled when we traced signaling. Going to take another look since there might be more problems, but for now: Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 1826ba73094c..1c1eaecaf1b0 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > &fence->flags))) > return; > > + trace_dma_fence_signaled(fence); > + > /* > * When neither a release nor a wait operation is specified set the ops > * pointer to NULL to allow the fence structure to become independent > @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > > fence->timestamp = timestamp; > set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); > - trace_dma_fence_signaled(fence); > > list_for_each_entry_safe(cur, tmp, &cb_list, node) { > INIT_LIST_HEAD(&cur->node);

1 week, 3 days

[PATCH v2] dma/contiguous: Fix broken build

by Maxime Ripard

Commit 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") didn't remove one last call to dma_heap_cma_register_heap() that it removed, thus breaking the build. That last call is in dma_contiguous_reserve(), to handle the registration of the default CMA region heap instance. The default CMA region instance is already somewhat handled by retrieving it through the dev_get_cma_area() call in the CMA heap driver. However, since commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"), we will create two heap instances for the CMA default region. The first one is always called "default_cma_region", and is the one handled by the call to dev_get_cma_area() mentioned earlier. The second one is the name it used to have prior to that last commit for backward compatibility. In the case where the default CMA region is defined in the DT, then that region is registered through rmem_cma_setup() and that region is added to the list of CMA regions to create a CMA heap instance for. In the case where the default CMA region is not defined in the DT though used to be the case covered by the now removed dma_heap_cma_register_heap() in dma_contiguous_reserve(). If we only remove the call to dma_heap_cma_register_heap(), then the legacy name of the CMA heap will not be registered anymore. We thus need to replace that call with a call to rmem_cma_insert_area() to make sure we queue this instance, if created, to create a heap instance. Once that call to dma_heap_cma_register_heap() replaced, we can also remove the now unused function definition, its now empty header, and all includes of this header. Fixes: 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") Reported-by: Mark Brown <broonie(a)kernel.org> Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@sirena.co.uk/ Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v2: - Fix creation of the CMA heap instance with the legacy name when not declared in the DT. - Link to v1: https://lore.kernel.org/r/20260330-dma-build-fix-v1-1-748b64f0d8af@kernel.o… --- drivers/dma-buf/heaps/cma_heap.c | 1 - include/linux/dma-buf/heaps/cma.h | 16 ---------------- kernel/dma/contiguous.c | 14 +++++++++++--- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 7216a14262b04bb6130ddf26b7d009f7d15b03fd..9a8b36bc929f6daa483a0139a2919d95127e0d23 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -12,11 +12,10 @@ #define pr_fmt(fmt) "cma_heap: " fmt #include <linux/cma.h> #include <linux/dma-buf.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-heap.h> #include <linux/dma-map-ops.h> #include <linux/err.h> #include <linux/highmem.h> #include <linux/io.h> diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heaps/cma.h deleted file mode 100644 index e751479e21e703e24a5f799b4a7fc8bd0df3c1c4..0000000000000000000000000000000000000000 --- a/include/linux/dma-buf/heaps/cma.h +++ /dev/null @@ -1,16 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef DMA_BUF_HEAP_CMA_H_ -#define DMA_BUF_HEAP_CMA_H_ - -struct cma; - -#ifdef CONFIG_DMABUF_HEAPS_CMA -int dma_heap_cma_register_heap(struct cma *cma); -#else -static inline int dma_heap_cma_register_heap(struct cma *cma) -{ - return 0; -} -#endif // CONFIG_DMABUF_HEAPS_CMA - -#endif // DMA_BUF_HEAP_CMA_H_ diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index ad50512d71d3088a73e4b1ac02d6e6122374888e..d5d15983060c5c54744d6a63f2b591e1a3455b86 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -40,11 +40,10 @@ #include <asm/page.h> #include <linux/memblock.h> #include <linux/err.h> #include <linux/sizes.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-map-ops.h> #include <linux/cma.h> #include <linux/nospec.h> #ifdef CONFIG_CMA_SIZE_MBYTES @@ -217,10 +216,19 @@ static void __init dma_numa_cma_reserve(void) static inline void __init dma_numa_cma_reserve(void) { } #endif +#ifdef CONFIG_OF_RESERVED_MEM +static int rmem_cma_insert_area(struct cma *cma); +#else +static inline int rmem_cma_insert_area(struct cma *cma) +{ + return 0; +} +#endif + /** * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling * @limit: End address of the reserved memory (optional, 0 for any). * * This function reserves memory from early allocator. It should be @@ -271,13 +279,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit) &dma_contiguous_default_area, fixed); if (ret) return; - ret = dma_heap_cma_register_heap(dma_contiguous_default_area); + ret = rmem_cma_insert_area(dma_contiguous_default_area); if (ret) - pr_warn("Couldn't register default CMA heap."); + pr_warn("Couldn't queue default CMA region for heap creation."); } } void __weak dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) --- base-commit: 6c683d5b1903a14e362c9f1628ce9fe61eac35e7 change-id: 20260330-dma-build-fix-706a4feb0e0f Best regards, -- Maxime Ripard <mripard(a)kernel.org>

1 week, 3 days

Re: [PATCH RESEND] dma-fence: Dereference correct dma_fence in dma_fence_chain_find_seqno()

by Christian König

On 3/28/26 11:26, Li Ming wrote: > > 在 2026/3/28 02:47, Li Ming 写道: >> dma_fence_chain_find_seqno() uses dma_fence_chain_for_each() to walk a >> given dma_fence_chain. dma_fence_chain_for_each() always holds a >> reference for the current fence during iteration. The reference must >> be dropped after breaking out. Instead of dereferencing the last fence >> as intended, dma_fence_chain_find_seqno() incorrectly dereferences the >> first fence in the chain. >> >> Fixes: 7bf60c52e093 ("dma-buf: add new dma_fence_chain container v7") >> Signed-off-by: Li Ming <ming.li(a)zohomail.com> >> --- >> drivers/dma-buf/dma-fence-chain.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c >> index a8a90acf4f34..71fa173aef13 100644 >> --- a/drivers/dma-buf/dma-fence-chain.c >> +++ b/drivers/dma-buf/dma-fence-chain.c >> @@ -103,7 +103,7 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno) >> to_dma_fence_chain(*pfence)->prev_seqno < seqno) >> break; >> } >> - dma_fence_put(&chain->base); >> + dma_fence_put(*pfence); >> return 0; >> } >> >> --- >> base-commit: c369299895a591d96745d6492d4888259b004a9e >> change-id: 20260327-fix_dma_fence_chain_find_seqno-7adea64efe01 >> >> Best regards, > > After looking deeper into this issue, it is not a bug. > > Seems like this function requires that caller needs to hold the reference of the give fence before calling it. When pfence changed, need to transfer the reference from the original fence to the new fence. That is why it releases the reference for the original fence in the end. Yeah exactly that. We have documented the behavior in the kerneldoc: * Advance the fence pointer to the chain node which will signal this sequence * number. But that is somehow not enough. If you have suggestions how to improve the comments then please speak up. This patch has been suggested as "fix" numerous times. Regards, Christian. > > Sorry to make this noise. > > > Ming >

1 week, 3 days

[PATCH] dma/contiguous: Fix broken build

by Maxime Ripard

1 week, 3 days

Expertise in Recovery

by penelopestaunton931＠gmail.com

Safeguard is not just another name in the crowded field of cryptocurrency recovery; they are renowned for their effectiveness and expertise in tracing lost funds. Their team comprises skilled professionals who understand the intricate workings of blockchain technology and the tactics employed by online scammers. This specialized knowledge enables them to devise tailored strategies to recover your assets. Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

1 week, 4 days

Why Choose Betafort Recovery

by brandonbarry676＠gmail.com

With professionalism and integrity, Betafort Recovery assures that their clients get the finest possible help in retrieving their lost digital assets. With a staff of professionals dedicated to assisting individuals in navigating the recovery process, they provide 24 hour support to guarantee that customers receive timely and effective assistance when they need it the most. Testimonials from delighted clients demonstrate Betafort Recovery abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Betafort Recovery

1 week, 4 days

Re: [RFC v2 PATCH 09/10] vfio/pci: Add mmap() attributes to DMABUF feature

by Jason Gunthorpe

On Thu, Mar 12, 2026 at 11:46:07AM -0700, Matt Evans wrote: > A new field is reserved in vfio_device_feature_dma_buf.flags to > request CPU-facing memory type attributes for mmap()s of the buffer. > Add a flag VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_WC, which results in WC > PTEs for the DMABUF's BAR region. This seems very straightforward, I like it Did I get it right that the idea is the user would request a dmabuf with these flags and then mmap the dmabuf? Jason

1 week, 4 days

Re: [RFC v2 PATCH 02/10] vfio/pci: Clean up DMABUFs before disabling function

by Jason Gunthorpe

On Thu, Mar 12, 2026 at 11:46:00AM -0700, Matt Evans wrote: > On device shutdown, make vfio_pci_core_close_device() call > vfio_pci_dma_buf_cleanup() before the function is disabled via > vfio_pci_core_disable(). This ensures that all access via DMABUFs is > revoked before the function's BARs become inaccessible. > > This fixes an issue where, if the function is disabled first, a tiny > window exists in which the function's MSE is cleared and yet BARs > could still be accessed via the DMABUF. The resources would also be > freed and up for grabs by a different driver. > > Fixes: 5d74781ebc86c ("vfio/pci: Add dma-buf export support for MMIO regions") > Signed-off-by: Matt Evans <mattev(a)meta.com> > --- > drivers/vfio/pci/vfio_pci_core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This seems like it should not be RFC and it should go to stable? The normal mmaps are cleaned because they hold the file open while they exist, dmabuf upends that and it does need zapping early. Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason

1 week, 4 days

← Newer
1
2
3
4
5
6
7
8
...
629
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig