Re: [RFC PATCH v2 4/5] dma-mapping: Refactor memory encryption usage

[Jason Gunthorpe]

On Mon, Mar 30, 2026 at 02:50:42PM +0000, Mostafa Saleh wrote:
> At the moment dma-direct deals with memory encryption in 2 cases
> - Pre-decrypted restricted dma-pools
> - Arch code through force_dma_unencrypted()
> 
> In the first case, the memory is owned by the pool and the decryption
> is not managed by the dma-direct.
> 
> However, it should be aware of it to use the appropriate phys_to_dma*
> and page table prot.
> 
> For the second case, it’s the job of the dma-direct to manage the
> decryption of the allocated memory.
> 
> As there have been bugs in this code due to wrong or missing
> checks and there are more use cases coming for memory decryption,
> we need more robust checks in the code to abstract the core logic,
> so introduce some local helpers:
> - dma_external_decryption(): For pages decrypted but managed externally
> - dma_owns_decryption(): For pages need to be decrypted and managed
>   by dma-direct
> - is_dma_decrypted(): To check if memory is decrypted

I can't even make sense of what this is trying to explain, talking
about page management along with 'dev' is nonsense. The management of
pages is intrinsic to the API, it doesn't change.

I think start with adding a direct flags annotation and then come back
to figure out if we need some kind of helpers.

I would expect any helper taking in dev to only be answering two dev 
questions:

  'dev can dma from encrypted(dev)'
  'dev can dma from unencrytped(dev)'

At each of the points in the API flow the phys under consideration is
known to be encrypted or decrypted, and those two helpers tell
everything needed.

So I'd expect the restricted flow to look more like

- phys comes in to be dma mapped, it is encrypted
- 'dev can dma from encrypted(dev)' fails so we go to swiotlb
- swiotlb allocates from a restricted pool, and learns through flags
  that the new phys is decrypted
- decrypted phys flows through the rest of the machinery.

We never check 'dev can dma from encrypted(dev)' a second time.

Jason