On Wed, May 20, 2026 at 09:27:27AM +0530, Aneesh Kumar K.V wrote: > Jason Gunthorpe <[email protected]> writes: > > > On Tue, May 19, 2026 at 09:35:30PM +0530, Aneesh Kumar K.V wrote: > >> Yes, that also resulted in simpler and cleaner code. > >> > >> swiotlb_tbl_map_single > >> /* > >> * If the physical address is encrypted but the device requires > >> * decrypted DMA, use a decrypted io_tlb_mem and update the > >> * attributes so the caller knows that a decrypted io_tlb_mem > >> * was used. > >> */ > >> if (!(*attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev)) > >> *attrs |= DMA_ATTR_CC_SHARED; > >> > >> if (mem->unencrypted != !!(*attrs & DMA_ATTR_CC_SHARED)) > >> return (phys_addr_t)DMA_MAPPING_ERROR; > > > > Yeah, exactly that is so much clearer now that the mem->unecrypted is > > tied directly. > > > > That logic is reversed though, the incoming ATTR_CC doesn't matter for > > swiotlb, that is just the source of the memcpy. > > > > /* swiotlb pool is incorrect for this device */ > > if (mem->unencrypted != force_dma_unencrypted(dev)) > > return (phys_addr_t)DMA_MAPPING_ERROR; > > > > /* Force attrs to match the kind of memory in the pool */ > > if (mem->unencrypted) > > *attrs |= DMA_ATTR_CC_SHARED; > > else > > *attrs &= ~DMA_ATTR_CC_SHARED; > > > > > > Attrs should be forced to whatever memory swiotlb selected. > > > > But that will not handle a T=1 device that wants to use swiotlb to > bounce unencrypted memory. That is: > > force_dma_unencrypted(dev) == 0 /* T=1 device */ > attrs = DMA_ATTR_CC_SHARED; > > In that case, it should use an unencrypted io_tlb_mem: > mem->unencrypted == 1
No! The DMA_ATTR_CC_SHARED only states the nature of the source memory, the DMA transfer will always happen under T=1 It is perfectly fine to memcpy from shared to private and do a T=1 DMA from the private memory if we have to bounce. Jason
