Hi, I know I'm late to the party here...
Like John, I'm also not very close to this stuff any more, but I agree with the other discussions: makes sense for this to be a separate heap, and cc_shared makes sense too. I'm not clear why the heap depends on !CONFIG_HIGHMEM, but I also don't know anything about SEV/TDX. -Brian On Wed, Mar 25, 2026 at 08:23:50PM +0000, Jiri Pirko wrote: > From: Jiri Pirko <[email protected]> > > Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, > run with private/encrypted memory which creates a challenge > for devices that do not support DMA to it (no TDISP support). > > For kernel-only DMA operations, swiotlb bounce buffering provides a > transparent solution by copying data through shared memory. > However, the only way to get this memory into userspace is via the DMA > API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits > the use of the memory to a single DMA device, and is incompatible with > pin_user_pages(). > > These limitations are particularly problematic for the RDMA subsystem > which makes heavy use of pin_user_pages() and expects flexible memory > usage between many different DMA devices. > > This patch series enables userspace to explicitly request shared > (decrypted) memory allocations from new dma-buf system_cc_shared heap. > Userspace can mmap this memory and pass the dma-buf fd to other > existing importers such as RDMA or DRM devices to access the > memory. The DMA API is improved to allow the dma heap exporter to DMA > map the shared memory to each importing device. > > Based on dma-mapping-for-next e7442a68cd1ee797b585f045d348781e9c0dde0d > > Jiri Pirko (2): > dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory > dma-buf: heaps: system: add system_cc_shared heap for explicitly > shared memory > > drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- > include/linux/dma-mapping.h | 10 +++ > include/trace/events/dma.h | 3 +- > kernel/dma/direct.h | 14 +++- > kernel/dma/mapping.c | 13 +++- > 5 files changed, 132 insertions(+), 11 deletions(-) > > -- > 2.51.1 >
