Re: [PATCH v2 0/8] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths

Jason Gunthorpe
2026-04-21T12:40:25Z

On Mon, Apr 20, 2026 at 11:44:07AM +0530, Aneesh Kumar K.V (Arm) wrote:
> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
> are handled consistently.
>
> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
> shared/decrypted buffer handling. This series consolidates the
> force_dma_unencrypted() checks in the top-level functions and ensures
> that the remaining DMA interfaces use DMA attributes to make the correct
> decisions.
>
> The series:
> - moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
> - propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free
> paths,
> - teaches the atomic DMA pools to track encrypted versus decrypted
> state,
> - tracks swiotlb pool encryption state and enforces strict pool
> selection,
> - centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
> DMA attributes,
> - makes dma_direct_map_phys() choose the DMA address encoding from
> attrs, and
> - uses the selected swiotlb pool state to derive the returned DMA
> address.

I think this is very reasonable looking.

Jason