From: Jiri Pirko jiri@nvidia.com
Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, run with encrypted/protected 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 decrypted 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 decrypted (shared) memory allocations from the dma-buf system 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.
--- v1->v2: patch1: - rebased on top of recent dma-mapping-fixes patch2: - fixed build errors on s390 by including mem_encrypt.h - converted system heap flag implementation to a separate heap
Based on dma-mapping-fixes HEAD d5b5e8149af0f5efed58653cbebf1cb3258ce49a
Jiri Pirko (2): dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory
drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- include/linux/dma-heap.h | 1 + include/linux/dma-mapping.h | 6 ++ include/trace/events/dma.h | 3 +- include/uapi/linux/dma-heap.h | 3 +- kernel/dma/direct.h | 14 +++- 6 files changed, 119 insertions(+), 11 deletions(-)