On Wed, Mar 25, 2026 at 12:23 PM Jiri Pirko <jiri(a)resnulli.us> 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>
Reviewed-by: T.J. Mercier <tjmercier(a)google.com>
On Thu, Mar 26, 2026 at 2:15 AM Danilo Krummrich <dakr(a)kernel.org> wrote:
>
> @Lyude, Alice, Miguel: Please have a look at what I came up with below.
Sounds fine to me, thanks!
- Regarding the enabled unstable feature: looks good -- it will go
away this cycle anyway, so we may get a conflict, but that is fine.
- Regarding the `&raw`, that sounds also good. I see you did it
similarly to how I did it for `bitmap.rs` -- thanks!
(And for future reference, the `bitmap.rs` one was 1.92 instead of
1.82 because that one was for unions, while this one is
https://blog.rust-lang.org/2024/10/17/Rust-1.82.0/#safely-addressing-unsafe…).
- Regarding the `expect(unused)` -- using `cfg_attr` is fine since
it is a simple case, but if it becomes a big issue, then of course
please feel free to use `allow` (you already know this, but in case it
helps others: I wrote some considerations about this at
https://docs.kernel.org/rust/coding-guidelines.html#lints).
Cheers,
Miguel
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 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 (8):
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
dma: contiguous: Export dev_get_cma_area()
mm: cma: Export cma_alloc(), cma_release() and 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 | 18 ++++++++++--------
kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++---
mm/cma.c | 3 +++
7 files changed, 60 insertions(+), 29 deletions(-)
---
base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916
change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a
Best regards,
--
Maxime Ripard <mripard(a)kernel.org>
Finally coming back to this patch set here.
Fell free to add Reviewed-by: Christian König <christian.koenig(a)amd.com> to the first two patches as well and then please start pushing the patches to amd-staging-drm-next.
I probably need to go over the last patches once more, but I think it would be better to have the first few upstream first.
Regards,
Christian.
On 2/3/26 11:22, Pierre-Eric Pelloux-Prayer wrote:
> The drm/ttm patch modifies TTM to support multiple contexts for the pipelined moves.
>
> Then amdgpu/ttm is updated to express dependencies between jobs explicitely,
> instead of relying on the ordering of execution guaranteed by the use of a single
> instance.
> With all of this in place, we can use multiple entities, with each having access
> to the available SDMA instances.
>
> This rework also gives the opportunity to merge the clear functions into a single
> one and to optimize a bit GART usage.
>
> Since v3 some patches have been already reviewed and merged separately:
> - https://lists.freedesktop.org/archives/amd-gfx/2026-January/137747.html
> - https://gitlab.freedesktop.org/drm/kernel/-/commit/ddf055b80a544d6f36f77be5…
> This version depend on them.
>
> v3: https://lists.freedesktop.org/archives/dri-devel/2025-November/537830.html
>
> Pierre-Eric Pelloux-Prayer (12):
> drm/amdgpu: allocate clear entities dynamically
> drm/amdgpu: allocate move entities dynamically
> drm/amdgpu: round robin through clear_entities in amdgpu_fill_buffer
> drm/amdgpu: use TTM_NUM_MOVE_FENCES when reserving fences
> drm/amdgpu: use multiple entities in amdgpu_move_blit
> drm/amdgpu: pass all the sdma scheds to amdgpu_mman
> drm/amdgpu: only use working sdma schedulers for ttm
> drm/amdgpu: create multiple clear/move ttm entities
> drm/amdgpu: give ttm entities access to all the sdma scheds
> drm/amdgpu: get rid of amdgpu_ttm_clear_buffer
> drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_ttm_clear_buffer
> drm/amdgpu: split amdgpu_ttm_set_buffer_funcs_status in 2 funcs
>
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 329 ++++++++++--------
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 29 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 13 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 15 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 12 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 11 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 14 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 5 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v7_0.c | 5 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v7_1.c | 12 +-
> drivers/gpu/drm/amd/amdgpu/si_dma.c | 12 +-
> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 5 +-
> drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 6 +-
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c | 6 +-
> 23 files changed, 300 insertions(+), 243 deletions(-)
>