On 29.08.2025 15:16, Jason Gunthorpe wrote: > On Tue, Aug 19, 2025 at 08:36:44PM +0300, Leon Romanovsky wrote: > >> This series does the core code and modern flows. A followup series >> will give the same treatment to the legacy dma_ops implementation. > I took a quick check over this to see that it is sane. I think using > phys is an improvement for most of the dma_ops implemenations. > > arch/sparc/kernel/pci_sun4v.c > arch/sparc/kernel/iommu.c > Uses __pa to get phys from the page, never touches page > > arch/alpha/kernel/pci_iommu.c > arch/sparc/mm/io-unit.c > drivers/parisc/ccio-dma.c > drivers/parisc/sba_iommu.c > Does page_addres() and later does __pa on it. Doesn't touch struct page > > arch/x86/kernel/amd_gart_64.c > drivers/xen/swiotlb-xen.c > arch/mips/jazz/jazzdma.c > Immediately does page_to_phys(), never touches struct page > > drivers/vdpa/vdpa_user/vduse_dev.c > Does page_to_phys() to call iommu_map() > > drivers/xen/grant-dma-ops.c > Does page_to_pfn() and nothing else > > arch/powerpc/platforms/ps3/system-bus.c > This is a maze but I think it wants only phys and the virt is only > used for debug prints. > > The above all never touch a KVA and just want a phys_addr_t. > > The below are touching the KVA somehow: > > arch/sparc/mm/iommu.c > arch/arm/mm/dma-mapping.c > Uses page_address to cache flush, would be happy with phys_to_virt() > and a PhysHighMem() > > arch/powerpc/kernel/dma-iommu.c > arch/powerpc/platforms/pseries/vio.c > Uses iommu_map_page() which wants phys_to_virt(), doesn't touch > struct page > > arch/powerpc/platforms/pseries/ibmebus.c > Returns phys_to_virt() as dma_addr_t. > > The two PPC ones are weird, I didn't figure out how that was working.. > > It would be easy to make map_phys patches for about half of these, in > the first grouping. Doing so would also grant those arches > map_resource capability. > > Overall I didn't think there was any reduction in maintainability in > these places. Most are improvements eliminating code, and some are > just switching to phys_to_virt() from page_address(), which we could > further guard with DMA_ATTR_MMIO and a check for highmem.
Thanks for this summary. However I would still like to get an answer for the simple question - why all this work cannot be replaced by a simple use of dma_map_resource()? I've checked the most advertised use case in https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio and I still don't see the reason why it cannot be based on dma_map_resource() API? I'm aware of the little asymmetry of the client calls is such case, indeed it is not preety, but this should work even now: phys = phys_vec[i].paddr; if (is_mmio) dma_map_resource(phys, len, ...); else dma_map_page(phys_to_page(phys), offset_in_page(phys), ...); What did I miss? I'm not against this rework, but I would really like to know the rationale. I know that the 2-step dma-mapping API also use phys addresses and this is the same direction. This patchset focuses only on the dma_map_page -> dma_map_phys rework. There are also other interfaces, like dma_alloc_pages() and so far nothing has been proposed for them so far. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
