On 02.04.2026 06:41, Sumit Semwal wrote: > On Thu, 26 Mar 2026 at 00:53, Jiri Pirko <[email protected]> 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. > Thank you for the patch series, it looks good to me. > > Marek, if you are ok, please could you take it through your tree, with my > Acked-by: Sumit Semwal <[email protected]>
I've applied both patches to dma-mapping-for-next. Thanks! Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
