Re: [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Apr 08, 2026 at 07:47:37PM +0000, Mostafa Saleh wrote:
> Introduction
> ============
> This is the third version of the fixes for direct-dma dealing with
> memory encryption and restricted-dma.
> 
> Changes in v3:
> - Instead of extending the logic by using is_swiotlb_for_alloc(),
>   follow Jason’s suggestion and propagate the state of the memory
>   allocated.
> - Remove checks out of dma_set_*() based on Jason suggestion
> - Remove documentation for now until we are close to the final
>   proposal and add it later if needed.

There are a number of Sashiko remarks that look plausible that should
be investigated:
https://sashiko.dev/#/patchset/20260408194750.2280873-1-smostafa%40google.com

> Design
> ======
> This series focuses mainly on dma-direct interaction with memory
> encryption which is the complicated case.
> At the moment memory encryption and dma-direct interacts in 2 ways:
> 1) force_dma_direct(): if true, memory will be decrypted by default
>    on allocation.
> 2) Restricted DMA: where memory is pre-decrypted and managed by
>    SWIOTLB.
> 
> With a third possible usage on the way [1] where the DMA-API allows
> an attr for decrypted memory.

This [1] was merged now

Jason