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

[Catalin Marinas <catalin.marinas@arm.com>]

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