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.

Changes from v2:
https://lore.kernel.org/all/20260420061415.3650870-1-aneesh.kumar@kernel.org
* pass attrs to dma_capable() and update direct, swiotlb, Xen swiotlb, and
  x86 GART paths so the capability checks see the DMA address attr value
  DMA_ATTR_CC_SHARED.
* rework dma_direct_map_phys() so DMA_ATTR_CC_SHARED selects
  phys_to_dma_unencrypted() while the default path uses
  phys_to_dma_encrypted(), with swiotlb fallback when the requested
  shared/private state cannot be satisfied by a direct DMA address.
* stop relying on SWIOTLB_FORCE for arm64 and x86 CC guest DMA mappings;
  swiotlb is still enabled there, but shared mappings is now selected
  through the generic dma_direct_map_phys()/dma_capable() decision instead
  of a global force-bounce flag.

Changes from v1:
https://lore.kernel.org/all/20260417085900.3062416-1-aneesh.kumar@kernel.org
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* update the alloc path so DMA_ATTR_CC_SHARED is not a caller-visible attribute.

Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jiri Pirko <jiri@resnulli.us> 
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mostafa Saleh <smostafa@google.com>
Cc: Petr Tesarik <ptesarik@suse.com> 
Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>

Aneesh Kumar K.V (Arm) (9):
  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: 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

 arch/arm64/mm/init.c          |   4 +-
 arch/x86/kernel/amd_gart_64.c |  30 +++---
 arch/x86/kernel/pci-dma.c     |   4 +-
 drivers/iommu/dma-iommu.c     |   2 +-
 drivers/xen/swiotlb-xen.c     |   9 +-
 include/linux/dma-direct.h    |  19 +++-
 include/linux/dma-map-ops.h   |   2 +-
 include/linux/swiotlb.h       |   7 +-
 kernel/dma/direct.c           | 189 ++++++++++++++++++++++++++--------
 kernel/dma/direct.h           |  32 +++---
 kernel/dma/mapping.c          |  16 ++-
 kernel/dma/pool.c             | 154 +++++++++++++++++----------
 kernel/dma/swiotlb.c          |  93 +++++++++++++----
 13 files changed, 393 insertions(+), 168 deletions(-)


base-commit: dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b
-- 
2.43.0

On Mon, Apr 27, 2026 at 11:25:00AM +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.

I think this series makes sense, using DMA_ATTR_CC_SHARED throughout the
DMA API, either for alloc or for streaming to decide/check what bouncing
does. Sashiko has a few interesting reports, it probably breaks s390 as
well (it might be similar to the pKVM case).

I don't think it addresses earlier Mostafa's issues with pKVM, although
I'd rather base additional pKVM related fixes on top of this series.
With pKVM, cc_platform_has(CC_ATTR_MEM_ENCRYPT) returns false, as does
force_dma_unencrypted(). I think we should update protected guests to
return true for these if they need shared buffers (the whole
decrypted/shared terminology is messy but in most places it just means
buffer not private to the protected guest, whether encryption is
available or not).

That said, does CC_ATTR_GUEST_MEM_ENCRYPT actually make more sense than
CC_ATTR_MEM_ENCRYPT throughout this series? We'd need to change arm64
realms as well to use this one.

-- 
Catalin

Catalin Marinas <catalin.marinas@arm.com> writes:

> On Mon, Apr 27, 2026 at 11:25:00AM +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.
>
> I think this series makes sense, using DMA_ATTR_CC_SHARED throughout the
> DMA API, either for alloc or for streaming to decide/check what bouncing
> does. Sashiko has a few interesting reports, it probably breaks s390 as
> well (it might be similar to the pKVM case).
>

I will address Shahiko’s review comments in the next revision.

With respect to s390/powerpc, I can drop SWIOTLB_FORCE from this series.
However, I was not sure whether we would get enough testing for that
soon. Both architectures are similar to x86/arm in forcing dma
unencrypted.

powerpc:
static inline bool force_dma_unencrypted(struct device *dev)
{
	return is_secure_guest();
}

s390:
/* are we a protected virtualization guest? */
bool force_dma_unencrypted(struct device *dev)
{
	return is_prot_virt_guest();
}


>
> I don't think it addresses earlier Mostafa's issues with pKVM, although
> I'd rather base additional pKVM related fixes on top of this series.
> With pKVM, cc_platform_has(CC_ATTR_MEM_ENCRYPT) returns false, as does
> force_dma_unencrypted(). I think we should update protected guests to
> return true for these if they need shared buffers (the whole
> decrypted/shared terminology is messy but in most places it just means
> buffer not private to the protected guest, whether encryption is
> available or not).
>
> That said, does CC_ATTR_GUEST_MEM_ENCRYPT actually make more sense than
> CC_ATTR_MEM_ENCRYPT throughout this series? We'd need to change arm64
> realms as well to use this one.
>

x86 memory encryption can use swiotlb boucing even on the host right?

+       if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
+               io_tlb_default_mem.decrypted = true;
+               set_memory_decrypted((unsigned long)mem->vaddr, bytes >> PAGE_SHIFT);
+       } else {
+               io_tlb_default_mem.decrypted = false;
+       }
+


-aneesh

On Fri, May 08, 2026 at 06:28:11PM +0100, Catalin Marinas wrote:
> On Mon, Apr 27, 2026 at 11:25:00AM +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.
> 
> I think this series makes sense, using DMA_ATTR_CC_SHARED throughout the
> DMA API, either for alloc or for streaming to decide/check what bouncing
> does. Sashiko has a few interesting reports, it probably breaks s390 as
> well (it might be similar to the pKVM case).

I have this series on my review list, I believe there is an overlap with
my series, I can rebase mine on top of this if that makes sense, I will
probably wait for a new version to address the current comments and
Sashiko notes.

Thanks,
Mostafa

> 
> I don't think it addresses earlier Mostafa's issues with pKVM, although
> I'd rather base additional pKVM related fixes on top of this series.
> With pKVM, cc_platform_has(CC_ATTR_MEM_ENCRYPT) returns false, as does
> force_dma_unencrypted(). I think we should update protected guests to
> return true for these if they need shared buffers (the whole
> decrypted/shared terminology is messy but in most places it just means
> buffer not private to the protected guest, whether encryption is
> available or not).
> 
> That said, does CC_ATTR_GUEST_MEM_ENCRYPT actually make more sense than
> CC_ATTR_MEM_ENCRYPT throughout this series? We'd need to change arm64
> realms as well to use this one.
> 
> -- 
> Catalin

On Mon, May 11, 2026 at 11:13:43AM +0000, Mostafa Saleh wrote:
> On Fri, May 08, 2026 at 06:28:11PM +0100, Catalin Marinas wrote:
> > On Mon, Apr 27, 2026 at 11:25:00AM +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.
> > 
> > I think this series makes sense, using DMA_ATTR_CC_SHARED throughout the
> > DMA API, either for alloc or for streaming to decide/check what bouncing
> > does. Sashiko has a few interesting reports, it probably breaks s390 as
> > well (it might be similar to the pKVM case).
> 
> I have this series on my review list, I believe there is an overlap with
> my series, I can rebase mine on top of this if that makes sense, I will
> probably wait for a new version to address the current comments and
> Sashiko notes.

I've been wondering about the two series as well.. I think this is a
big help to your project, but it would be nice to know??

Jason

On Fri, May 08, 2026 at 06:28:11PM +0100, Catalin Marinas wrote:

> That said, does CC_ATTR_GUEST_MEM_ENCRYPT actually make more sense than
> CC_ATTR_MEM_ENCRYPT throughout this series? We'd need to change arm64
> realms as well to use this one.

It is often quite confusing in the DMA API and iommu what is guest
logic and what is host logic, so this does sound nice. AFAIK none of
this forced bouncing, T=1 or CC_SHARED logic applies to host in the
DMA API.

Jason