Tue, Mar 17, 2026 at 02:24:13PM +0100, [email protected] wrote: >Hi Jiri, > >On Thu, Mar 05, 2026 at 01:36:39PM +0100, Jiri Pirko wrote: >> From: Jiri Pirko <[email protected]> >> >> 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. > >I have been looking into a similar problem with restricted-dma[1] and >the inability of the DMA API to recognize that a block of memory is >already decrypted. > >However, in your case, adding a new attr “DMA_ATTR_CC_DECRYPTED” works >well as dma-buf owns the memory, and is both responsible for the >set_memory_decrypted() and passing the DMA attrs. > >On the other hand, for restricted-dma, the memory decryption is deep >in the DMA direct memory allocation and the DMA API callers (for ex >virtio drivers) are clueless about it and can’t pass any attrs. >My proposal was specific to restricted-dma and won’t work for your case. > >I am wondering if the kernel should have a more solid, unified method >for identifying already-decrypted memory instead. Perhaps we need a >way for the DMA API to natively recognize the encryption state of a >physical page (working alongside force_dma_unencrypted(dev)), rather >than relying on caller-provided attributes?
I actually had it originally implemented probably in the similar way you suggest. I had a bit in page/folio struct to indicate the "shared/decrypted" state. However I was told that adding such bit is basically a no-go. Isn't that right? > >[1] https://lore.kernel.org/all/[email protected]/ > >Thanks, >Mostafa > > >> >> 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-mapping.h | 6 ++ >> include/trace/events/dma.h | 3 +- >> kernel/dma/direct.h | 14 +++- >> 4 files changed, 117 insertions(+), 9 deletions(-) >> >> -- >> 2.51.1 >>
