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
1) 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.
2) 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.
