On Tue, Mar 24, 2026 at 5:57 PM Jason Gunthorpe <[email protected]> wrote: > > On Tue, Mar 24, 2026 at 05:36:23PM +0000, Mostafa Saleh wrote: > > 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 don't understand how this can be, ownership is clear. SWIOTLB owns > the buffer, dma alloc coherent owns the buffer, user owns the > buffer. There should be no other cases, and they don't step on each > other unless the APIs are being used wrong. >
Logically, that's the case, but the DMA-direct code currently loses this information and assumes it can encrypt/decrypt any memory even the SWIOTLB one. That's what I am fixing in my series. When I respin, I can try to introduce some more helpers around that to make it easier to integrate new cases. Thanks, Mostafa > > 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. > > Redoingt how dma-api works internally is some other project... It > would be nice if swiotlb would sort of recursively DMA map using the > new flag instead of open coding it but that is pretty minor. > > Jason
