Catalin Marinas <[email protected]> writes: > On Thu, Jun 04, 2026 at 02:09:39PM +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. >> >> 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. > > Please check Sashiko's reports, it has some good points: > > https://sashiko.dev/#/patchset/[email protected] > > I think the main one is the swiotlb_tbl_map_single() changes which break > AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true > but force_dma_unencrypted() is false. Normally you'd not end up on this > path but you can have swiotlb=force. >
I would consider the above similar to a trusted device requiring swiotlb bouncing. At some point, based on real-world use cases, we may need to add protected io_tlb_mem pools. We have not done that yet because no such use case has come so far. -aneesh
