On Tue, Mar 24, 2026 at 12:14:36PM +0000, Mostafa Saleh wrote: > 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]
I fully belive there are bugs, but the API design is sound. If you use the coherent allocations from the DMA API then it knows decryption has happened when it generates a dma_addr_t and there should be no issue. Now, if drivers are using the DMA API wrong, like trying to double map coherent allocations then they are broken. I also would not be surprised to find cases like this. Jason
