Re: [PATCH v7 00/22] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths

[Will Deacon]

On Tue, Jul 07, 2026 at 03:03:48PM +0200, Marek Szyprowski wrote:
> On 07.07.2026 10:06, Aneesh Kumar K.V wrote:
> > "Aneesh Kumar K.V (Arm)" <aneesh.kumar@xxxxxxxxxx> writes:
> >
> >> This series tracks confidential-computing shared DMA state 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 separates mapping and allocation state:
> >> - DMA_ATTR_CC_SHARED describes the DMA address attribute requested for a
> >>   mapping. It tells the DMA mapping path that the DMA address must target
> >>   shared/decrypted memory.
> >> - __DMA_ATTR_ALLOC_CC_SHARED is an internal DMA-mapping attribute used only
> >>   by allocation paths after the DMA core decides that the backing pages
> >>   must be allocated as shared/decrypted memory.
> >>
> >> The series:
> >> - moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
> >> - uses __DMA_ATTR_ALLOC_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
> >> - passes DMA attributes down to dma_capable() so capability checks can
> >>   validate whether the selected DMA address encoding matches
> >>   DMA_ATTR_CC_SHARED
> >> - makes dma_direct_map_phys() choose the DMA address encoding from
> >>   DMA_ATTR_CC_SHARED and fall back to swiotlb when a shared DMA request
> >>   cannot use the direct mapping, which lets arm64 and x86 CCA guests stop
> >>   relying on SWIOTLB_FORCE for DMA mappings
> >> - use the selected swiotlb pool state to derive the returned DMA
> >>   address
> >> - reports CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
> >>   guests, and s390 protected virtualization guests.
> >>
> >> Dependency:
> >> This series depends on the pKVM changes posted at:
> >> https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@xxxxxxxxxx

FYI, I'll probably take the second patch there as a fix, then I can put
the other two on a topic branch in the arm64 tree.

Will