On Tue, Mar 24, 2026 at 12:24 PM Jason Gunthorpe <[email protected]> wrote: > > 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. >
But it's not about drivers in that case, it's about many places (SWIOTLB and DMA-direct) calling set_memory_decrypted() without clear ownership so in some cases they step on each other's toes, and I don't think that will get simpler with yet another caller in this series I am fine with the API design you mentioned, but I believe that it needs clear documentation specifying who is responsible for decryption. The code should provide wrappers checking for these cases instead of having is_swiotlb_for_alloc() and force_dma_unencrypted() everywhere in DMA-direct. Thanks, Mostafa > Jason
