Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

[Bastien Curutchet]

Hi Christian,

On 4/11/25 9:30 AM, Christian König wrote:
> Hi Thomas,
>
> Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
> > Hello Christian,
> >
> > Thanks for your feedback!
> >
> > On Thu, 10 Apr 2025 18:29:12 +0200
> > Christian König<christian.koenig@xxxxxxx> wrote:
> >
> > > > Many UIO users performing DMA from their UIO device need to access the
> > > > DMA addresses of the allocated buffers. There are out-of-tree drivers
> > > > that allow to do it but nothing in the mainline.
> > > Well that basically disqualifies this patch set in the first paragraph.
> > >
> > > To justify some kernel change we always need an in kernel user of the
> > > interface, since this is purely for out-of-tree drivers this is a
> > > no-go to begin with.
> > I'm not sure to understand your comment here. This patch series is
> > about extending the UIO interface... which is a user-space interface.
> > So obviously it has no "in-kernel user" because it's meant to be used
> > from user-space. Could you clarify what you meant here?
>
> Bastien wrote about "out-of-tree drivers" which is something the 
> upstream kernel explicitly does not support.

Sorry maybe it wasn't clear, but what I meant is that the goal of this 
series is to replace 'out-of-tree drivers' with something upstream.

> When you make that UIO API and have an open source userspace driver then 
> that is probably a good justification to do this.
>
> What the kernel community tries to prevent here is that people start 
> using the UAPI to write closed source drivers in userspace.

> > > What you could potentially do is to create an UIO driver which
> > > imports DMA-bufs, pins them and then provide the DMA addresses to
> > > userspace.
> > >
> > > But please be aware that DMA-fences are fundamentally incompatible
> > > with UIO. So you won't be able to do any form of synchronization
> > > which probably makes the implementation pretty limited.
> > Could you clarify why DMA-fences would be needed here, and for what
> > synchronization?
>
> In general DMA-buf is an interface which enables you do share device 
> specific buffers between different drivers as well as between userspace 
> processes.
>
> For this to work with for example cameras, GPUs or RDMA NICs you need to 
> some kind of synchronization primitive, e.g. device A can only starts 
> it's DMA transaction when device B has completed his.
>
> The problem is that this synchronization approach is fundamentally 
> incompatible with UIO. See here for more details: https:// 
> www.kernel.org/doc/html/latest/driver-api/dma-buf.html#indefinite-dma-fences
>
> > The DMA buffers allocated here are DMA coherent buffers. So the
> > user-space application that uses UIO will allocate such buffers once at
> > application start, retrieve their DMA address, and then program DMA
> > transfers as it sees fit using the memory-mapped registers accessible
> > through UIO. I'm not sure which synchronization you are referring to.
> > We are not "chaining" DMA transfers, with for example a camera
> > interface feeding its DMA buffers to an ISP or something like that. The
> > typical use case here is some IP block in an FPGA that does DMA
> > transfers to transfer data to/from some sort of specialized I/O
> > interface. We get an interrupt when the transfer is done, and we can
> > re-use the buffer for the next transfer.
>
> Well why do you then want to use DMA-buf in the first place? As far as I 
> know what you describe can perfectly be done with the normal UIO memory 
> management interfaces.
>
> DMA-buf is only interesting when you actually want to share something in 
> between devices or between applications.

I wanted to use DMA-buf because it allows to dynamically 
allocate/release coherent buffers from userspace. UIO doesn't provide 
such interface.
I'm aware that exposing DMA addresses to userspace isn't a good 
practice. That's why this series create a new heap specific to UIO that 
will be the only one implementing the new ioctl.


Best regards,
Bastien