On 2022-09-07 16:23, Jason Gunthorpe wrote:
On Wed, Sep 07, 2022 at 07:29:58AM -0700, Christoph Hellwig wrote:
On Wed, Sep 07, 2022 at 09:33:11AM -0300, Jason Gunthorpe wrote:
Yes, you said that, and I said that when the AMD driver first merged it - but it went in anyhow and now people are using it in a bunch of places.
drm folks made up their own weird rules, if they internally stick to it they have to listen to it given that they ignore review comments, but it violates the scatterlist API and has not business anywhere else in the kernel. And yes, there probably is a reason or two why the drm code is unusually error prone.
That may be, but it is creating problems if DRM gets to do X crazy thing and nobody else can..
So, we have two issues here
DMABUF abuses the scatter list, but this is very constrainted we have this weird special "DMABUF scatterlist" that is only touched by DMABUF importers. The imports signal that they understand the format with a flag. This is ugly and would be nice to clean to a dma mapped address list of some sort.
I spent alot of time a few years ago removing driver touches of the SGL and preparing the RDMA stack to do this kind of change, at least.
DMABUF abuses dma_map_resource() for P2P and thus doesn't work in certain special cases.
FWIW, dma_map_resource() *is* for P2P in general. The classic case of one device poking at another's registers that was the original motivation is a standalone DMA engine reading/writing a peripheral device's FIFO, so the very similar inter-device doorbell signal is absolutely in scope too; VRAM might be a slightly greyer area, but if it's still not page-backed kernel memory then I reckon that's fair game.
The only trouble is that it's not geared for *PCI* P2P when that may or may not happen entirely upstream of IOMMU translation.
Robin.