On Tue, Mar 24, 2026 at 12:01 PM Jason Gunthorpe <[email protected]> wrote: > > On Tue, Mar 17, 2026 at 01:24:13PM +0000, Mostafa Saleh wrote: > > > 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. > > How is this any different from CC? > > If the device cannot dma to "encrypted" memory, whatever that means > for you, then the DMA API: > - Makes dma alloc coherent return "decrypted" memory, and the built > in mapping of coherent memory knows about this > - Makes dma_map_xxx use SWIOTLB to bounce to decrypted memory > > There is no need for something like virtio drivers to be aware of > any of this. > > On the other hand if the driver deliberately allocates decrypted > memory without using DMA API alloc coherent then it knows it did it > and can pass the flag to map it. >
The problem is that the DMA API currently gets confused by this; it can end up double decrypting the memory or using the wrong functions as mentioned in [1] In addition to the complexity it adds to the already complicated DMA code. I don't have a strong opinion on how to solve this, but I believe we need clear boundaries (and wrappers) for cases where memory encryption is expected as it is starting to spill into the kernel. [1] https://lore.kernel.org/all/[email protected]/ Thanks, Mostafa > > 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? > > Definately not, we do not want the DMA API inspecting things like > this. > > Jason
