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

[Aneesh Kumar K . V]

Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> writes:

> On 25.07.2026 09:09, 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
>>>
>>> Please merge this series only after the pKVM changes above are merged.
>>> Otherwise pKVM will be broken.
>>>
>> pKVM topic branch is now available 
>>
>> https://lore.kernel.org/all/178467286876.125042.12010461715645610054.b4-ty@xxxxxxxxxx/
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/coco
> I've just got back from my holiday's and I see that there is everything ready to give
> this patchset some tests in linux-next. I hope nothing will break.
>
> I've applied this patchset to dma-mapping-for-next, on top of pKVM topic branch with
> patch "[PATCH v8 17/23] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED"
> rebased onto latest changes in arch/arm64/mm/init.c.
>

That might need a fix.