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

Thomas Petazzoni
2025-04-14T09:03:53Z

Hello Christoph,

On Sun, 13 Apr 2025 22:55:02 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Apr 10, 2025 at 04:53:17PM +0200, Bastien Curutchet wrote:
> > Hi all,
> >
> > 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.
>
> In which case it does not matter at all for mainline.

It is impressive how "out-of-tree" triggers kernel maintainers, and
then end up not even reading what the patch series is all about (but I
forgive you, because it triggers me in the same way).

This patch series is NOT about adding new kernel APIs meant to be used
by out-of-tree drivers, which of course would be bad, and we would have
never proposed.

What this patch series is about is to add new user-space interface to
extend the existing UIO subsystem. What my colleague Bastien was
mentioning about out-of-tree drivers is that there are a LOT of
out-of-tree drivers extending UIO to allow user-space applications to
do DMA, and our proposal is that considering how many people need that
and implement ugly out-of-tree drivers to solve this issue, we suggest
the mainline kernel should have a built in solution.

Please re-read again, and realize that we are NOT adding new kernel
APIs for out-of-tree drivers.

> FYI the proper and safe way to do DMA from userspace is to use
> vfio/iommufd.

I am not sure how this can work in our use-case. We have a very simple
set of IP blocks implemented in a FPGA, some of those IP blocks are
able to perform DMA operations. The register of those IP blocks are
mapped into a user-space application using the existing, accepted
upstream, UIO subsystem. Some of those registers allow to program DMA
transfers. So far, we can do all what we need, except program those DMA
transfers. Lots of people are having the same issue, and zillions of
ugly out-of-tree solutions flourish all over, and we're trying to see
if we can constructively find a solution that would be acceptable
upstream to resolve this use-case. Our platform is an old PowerPC with
no IOMMU.

Note that the safety argument doesn't hold: UIO already allows to map
registers into user-space applications, which can already program DMA
transfers to arbitrary locations in memory. The safety comes from the
fact that such UIO devices are associated with permissions that the
system administrator controls, to decide which applications are safe
enough to be granted access to those UIO devices. Therefore, providing
access through UIO of the physical address of well-defined DMA buffers
properly allocated through a sane API is not reducing the safety of
anything compared to what UIO already allows today.

Best regards,

Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training