On Fri, Mar 27, 2026 at 5:10 AM Jason Gunthorpe <[email protected]> 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 <[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 > > > > 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.
