On Tue, Mar 24, 2026 at 12:14:36PM +0000, Mostafa Saleh wrote:
On Tue, Mar 24, 2026 at 12:01 PM Jason Gunthorpe jgg@ziepe.ca 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