Thread (48 messages) 48 messages, 9 authors, 2021-06-24

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

From: Christoph Hellwig <hch@lst.de>
Date: 2021-06-24 08:12:46
Also in: amd-gfx, linux-media, lkml

On Thu, Jun 24, 2021 at 10:07:14AM +0200, Christian König wrote:
The key point is that accessing the underlying pages even when DMA-bufs are 
backed by system memory is illegal. Daniel even created a patch which 
mangles the page pointers in sg_tables used by DMA-buf to make sure that 
people don't try to use them.
Which is another goddamn layering violation of a subsystem that has no
business at all poking into the scatterlist structure, yes.
So the conclusion is that using sg_table in the DMA-buf framework was just 
the wrong data structure and we should have invented a new one.
I think so.
But then people would have complained that we have a duplicated 
infrastructure (which is essentially true).
I doubt it.  At least if you had actually talked to the relevant people.
Which seems to be a major issue with what is going on GPU land.
My best plan to get out of this mess is that we change the DMA-buf 
interface to use an array of dma_addresses instead of the sg_table object 
and I have already been working on this actively the last few month.
Awesome!  I have a bit of related work on the DMA mapping subsystems, so
let's sync up as soon as you have some first sketches.

Btw, one thing I noticed when looking over the dma-buf instances is that
there is a lot of duplicated code for creating a sg_table from pages,
and then mapping it.  It would be good if we could move toward common
helpers instead of duplicating that all over again.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help