On Wed, Aug 26, 2026 at 03:31:12PM -0300, Jason Gunthorpe wrote: > On Wed, Jul 08, 2026 at 11:48:44PM +0000, Samiullah Khawaja wrote: > > This is an RFC v2 to discuss the preservation of DMA allocations for > > devices that are using direct allocation mode. Note preservation here > > means preservation of physical memory using KHO only. IOVAs and IOMMU > > mappings are out of scope. > > > > The complexity and need of this was discussed in the thread mentioned > > below. It was proposed to allow preservation of only a subset of > > allocations with minimum support. Offline discussion with Will Deacon > > concluded that this series is still needed, because we still want to use > > coherent allocations for Arm sMMUv3 ste/cds, so sending this v2. > > Was this before or after concluding that ARM was OK with using > cachable memory?
That discussion was primarily about the page-tables iirc. I still think drivers should be able to use the coherent DMA API and not have to use an entirely different interface depending on whether or not they need to support KHO. > > include/linux/dma-direct.h | 29 +++++ > > include/linux/dma-map-ops.h | 10 ++ > > include/linux/dma-mapping.h | 100 ++++++++++++++ > > include/linux/kho/abi/dma_alloc.h | 32 +++++ > > kernel/dma/Kconfig | 12 ++ > > kernel/dma/Makefile | 1 + > > kernel/dma/coherent.c | 11 ++ > > kernel/dma/contiguous.c | 27 ++++ > > kernel/dma/direct.c | 189 +++++++++++++++++++++++++++ > > kernel/dma/direct_test.c | 208 ++++++++++++++++++++++++++++++ > > kernel/dma/mapping.c | 132 +++++++++++++++++++ > > kernel/dma/pool.c | 17 +++ > > 12 files changed, 768 insertions(+) > > Because this seems like quite a big change to swallow compared to just > using iommu pages.h Maybe, but I think it's in the right place rather than scattered across a bunch of drivers. A good chunk of it is also test code and empty static inline functions. Will
