On Wed, Jan 08, 2025 at 02:44:26PM +0100, Christian König wrote: > > Having the importer do the mapping is the correct way to operate the > > DMA API and the new API that Leon has built to fix the scatterlist > > abuse in dmabuf relies on importer mapping as part of it's > > construction. > > Exactly on that I strongly disagree on. > > DMA-buf works by providing DMA addresses the importer can work with and > *NOT* the underlying location of the buffer. The expectation is that the DMA API will be used to DMA map (most) things, and the DMA API always works with a physaddr_t/pfn argument. Basically, everything that is not a private address space should be supported by improving the DMA API. We are on course for finally getting all the common cases like P2P and MMIO solved here. That alone will take care of alot. For P2P cases we are going toward (PFN + P2P source information) as input to the DMA API. The additional "P2P source information" provides a good way for co-operating drivers to represent private address spaces as well. Both importer and exporter can have full understanding what is being mapped and do the correct things, safely. So, no, we don't loose private address space support when moving to importer mapping, in fact it works better because the importer gets more information about what is going on. I have imagined a staged approach were DMABUF gets a new API that works with the new DMA API to do importer mapping with "P2P source information" and a gradual conversion. Exporter mapping falls down in too many cases already: 1) Private addresses spaces don't work fully well because many devices need some indication what address space is being used and scatter list can't really properly convey that. If the DMABUF has a mixture of CPU and private it becomes a PITA 2) Multi-path PCI can require the importer to make mapping decisions unique to the device and program device specific information for the multi-path. We are doing this in mlx5 today and have hacks because DMABUF is destroying the information the importer needs to choose the correct PCI path. 3) Importing devices need to know if they are working with PCI P2P addresses during mapping because they need to do things like turn on ATS on their DMA. As for multi-path we have the same hacks inside mlx5 today that assume DMABUFs are always P2P because we cannot determine if things are P2P or not after being DMA mapped. 4) TPH bits needs to be programmed into the importer device but are derived based on the NUMA topology of the DMA target. The importer has no idea what the DMA target actually was because the exporter mapping destroyed that information. 5) iommufd and kvm are both using CPU addresses without DMA. No exporter mapping is possible Jason
