On Thu, Jun 18, 2026 at 09:37:22AM +0100, Aneesh Kumar K.V wrote: > Alexey Kardashevskiy <[email protected]> writes: > > > On 10/6/26 00:47, Jason Gunthorpe wrote: > >> On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote: > >>> 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. > >> > >> IMHO that's an AMD issue, not with the design of this series.. > >> > >> The series is right, a device that is !force_dma_decrypted() must be > >> considerd to be a trusted device and we must never place any DMA > >> mappings for a trusted device into shared memory. > > > > swiotlb=force forces swiotlb, not decryption.
If force_dma_decrypted() == true then swiotlb must allocate from a decrypted memory pool. It is right there in the name! The hypervisor environment should *never* set force_dma_decrypted() because all devices can access all hypervisor memory, up to their IOVA limits. > > So when I try "mem_encrypt=on iommu=pt swiotlb=force" with this > > patchset, it fails to boot. But it boots with a hack like this: On the host side I expect this to cause swiotlb to allocate encrypted memory and bounce to it. > u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask)); > u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask, > dev->bus_dma_limit); > + /* > + * With memory encryption enabled, SWIOTLB is marked decrypted. > + * If SWIOTLB bouncing is forced, treat the device as requiring > + * decrypted DMA. > + */ And this is more insane logic. The right fix is to allocate the swiotlb bounce from the *encrypted* pools when running on the hypervisor which requires undoing this abuse of force_dma_decrypted(). Jason
