[PATCH v5 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths

[Michael Kelley]

From: Aneesh Kumar K.V (Arm) <aneesh.kumar at kernel.org> Sent: Thursday, May 21, 2026 9:28 PM
> 
> 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
> - 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.

[snip]

> 
> 
> Aneesh Kumar K.V (Arm) (20):
>   [DO NOT MERGE] arm64/coco: Add pKVM as a CC platform
>   [DO NOT MERGE] s390: Expose protected virtualization through
>     cc_platform_has()
>   dma-direct: swiotlb: handle swiotlb alloc/free outside
>     __dma_direct_alloc_pages
>   dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
>   dma-pool: track decrypted atomic pools and select them via attrs
>   dma: swiotlb: pass mapping attributes by reference
>   dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
>   dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED
>   dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
>   dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
>   dma-direct: set decrypted flag for remapped DMA allocations
>   dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED
>   dma-pool: fix page leak in atomic_pool_expand() cleanup
>   dma-direct: rename ret to cpu_addr in alloc helpers
>   dma-direct: return struct page from dma_direct_alloc_from_pool()
>   iommu/dma: Check atomic pool allocation result directly
>   dma: swiotlb: free dynamic pools from process context
>   dma: swiotlb: handle set_memory_decrypted() failures
>   dma: free atomic pool pages by physical address
>   swiotlb: Preserve allocation virtual address for dynamic pools
> 
>  arch/arm64/include/asm/hypervisor.h           |   6 +
>  arch/arm64/include/asm/mem_encrypt.h          |   3 +-
>  arch/arm64/kernel/rsi.c                       |  12 -
>  arch/arm64/mm/init.c                          |  17 +-
>  arch/powerpc/platforms/pseries/svm.c          |   2 +-
>  arch/s390/Kconfig                             |   1 +
>  arch/s390/mm/init.c                           |  16 +-
>  arch/x86/kernel/amd_gart_64.c                 |  30 +-
>  arch/x86/kernel/pci-dma.c                     |   4 +-
>  drivers/iommu/dma-iommu.c                     |  15 +-
>  drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c |   5 +
>  drivers/xen/swiotlb-xen.c                     |   8 +-
>  include/linux/dma-direct.h                    |  20 +-
>  include/linux/dma-map-ops.h                   |   3 +-
>  include/linux/swiotlb.h                       |  20 +-
>  kernel/dma/direct.c                           | 275 +++++++++++++-----
>  kernel/dma/direct.h                           |  47 +--
>  kernel/dma/mapping.c                          |  16 +-
>  kernel/dma/pool.c                             | 221 ++++++++++----
>  kernel/dma/swiotlb.c                          | 270 +++++++++++++----
>  20 files changed, 717 insertions(+), 274 deletions(-)
> 

I tested the series in a linux-next20260518 kernel, running in an
Azure VM on the Hyper-V hypervisor. The physical processor is Intel
XEON(R) PLATINUM 8573C with TDX memory encryption in use, so
this is a Linux CoCo VM. The VM has the usual VMBus synthetic disk
and network devices provided by Hyper-V, plus two PCI NVMe devices
that are directly assigned to the VM. I did basic smoke tests in the
VM, including reading and writing the NVMe devices. The swiotlb is
used as expected for DMA transfers to/from the synthetic and NVMe
devices. The NVMe driver does dma_alloc_coherent() to allocate
memory for control structures that must be decrypted. I did "unbind"
on the NVMe devices, and then rebound them so the dma allocations
would be freed and then reallocated. All looks good.

I'd like to try the same tests in a CoCo VM based on AMD SEV-SNP,
but I need to get quota for that VM size in Azure, and I don't know
how soon that can happen.

So as described above,

Tested-by: Michael Kelley <mhklinux at outlook.com>