Re: [PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory
On 25.03.2026 20:23, Jiri Pirko wrote:
From: Jiri Pirko jiri@nvidia.com
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
I would like to merge this to dma-mapping-next, but I feel a bit uncomfortable with my lack of knowledge about CoCo and friends. Could those who know a bit more about it provide some Reviewed-by tags?
Best regards
On Fri, Mar 27, 2026 at 10:38:10AM +0100, Marek Szyprowski wrote:
On 25.03.2026 20:23, Jiri Pirko wrote:
From: Jiri Pirko jiri@nvidia.com
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
I would like to merge this to dma-mapping-next, but I feel a bit uncomfortable with my lack of knowledge about CoCo and friends. Could those who know a bit more about it provide some Reviewed-by tags?
I'm confident in the CC stuff, I was hoping to see someone from dmabuf heap land ack that the uAPI design is OK.. TJ?
Jason
On Fri, Mar 27, 2026 at 5:10 AM Jason Gunthorpe jgg@ziepe.ca wrote:
On Fri, Mar 27, 2026 at 10:38:10AM +0100, Marek Szyprowski wrote:
On 25.03.2026 20:23, Jiri Pirko wrote:
From: Jiri Pirko jiri@nvidia.com
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
I would like to merge this to dma-mapping-next, but I feel a bit uncomfortable with my lack of knowledge about CoCo and friends. Could those who know a bit more about it provide some Reviewed-by tags?
I'm confident in the CC stuff, I was hoping to see someone from dmabuf heap land ack that the uAPI design is OK.. TJ?
Jason
Hi, yes LGTM. From a uAPI perspective it's just another dma-buf heap.
linaro-mm-sig@lists.linaro.org
-
Jason Gunthorpe -
Marek Szyprowski -
T.J. Mercier