Re: [PATCH v7 07/22] dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages
Jason Gunthorpe <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 01, 2026 at 11:19:11AM +0530, Aneesh Kumar K.V (Arm) wrote: > Move swiotlb allocation out of __dma_direct_alloc_pages() and handle it in > dma_direct_alloc() / dma_direct_alloc_pages(). > > This is needed for follow-up changes that simplify the handling of > memory encryption/decryption based on the DMA attribute flags. > > swiotlb backing pages are already mapped decrypted by > swiotlb_update_mem_attributes() and rmem_swiotlb_device_init(), so > dma-direct should not call dma_set_decrypted() on allocation nor > dma_set_encrypted() on free for swiotlb-backed memory. > > Update alloc/free paths to detect swiotlb-backed pages and skip > encrypt/decrypt transitions for those paths. Keep the existing highmem > rejection in dma_direct_alloc_pages() for swiotlb allocations. > > Only for "restricted-dma-pool", we currently set `for_alloc = true`, while > rmem_swiotlb_device_init() decrypts the whole pool up front. This pool is > typically used together with "shared-dma-pool", where the shared region is > accessed after remap/ioremap and the returned address is suitable for > decrypted memory access. So existing code paths remain valid. > > Tested-by: Jiri Pirko <[email protected]> > Tested-by: Michael Kelley <[email protected]> > Tested-by: Mostafa Saleh <[email protected]> > Signed-off-by: Aneesh Kumar K.V (Arm) <[email protected]> > --- > include/linux/swiotlb.h | 6 ++++ > kernel/dma/direct.c | 71 ++++++++++++++++++++++++++++++----------- > kernel/dma/swiotlb.c | 6 ++++ > 3 files changed, 65 insertions(+), 18 deletions(-) Reviewed-by: Jason Gunthorpe <[email protected]> Jason