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

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

[Bastien Curutchet]

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.

I know DMA shouldn't be handled by userspace but, IMHO, since UIO
drivers exist, it would be better if they offered a way of doing this.

This patch series use the dma-heap framework which already allows
userspace to allocate DMA buffers. I tried to avoid 'polluting' the
existing heaps to prevent inappropriate uses of this new feature by
introducing a new UIO heap, which is the only one implementing this
behavior.

PATCH 1 allows the creation of heaps that don't implement map/unmap_buf
operations as UIO heap doesn't use them.
PATCH 2 adds the DMA_BUF_IOCTL_GET_DMA_ADDR which transmits the DMA
addresses to userspace.
PATCH 3 implements the UIO heap.

It has been tested with the uio_pci_generic driver on a PowerPC.

Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
---
Bastien Curutchet (3):
      dma-buf: Allow heap that doesn't provide map_buf/unmap_buf
      dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR
      uio: Add UIO_DMABUF_HEAP

 drivers/dma-buf/dma-buf.c    |  29 +++++++++--
 drivers/uio/Kconfig          |   9 ++++
 drivers/uio/Makefile         |   1 +
 drivers/uio/uio.c            |   4 ++
 drivers/uio/uio_heap.c       | 120 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/dma-buf.h      |   1 +
 include/linux/uio_driver.h   |   2 +
 include/uapi/linux/dma-buf.h |   1 +
 8 files changed, 164 insertions(+), 3 deletions(-)
---
base-commit: 5f13fa25acaa4f586aaed12efcf7436e004eeaf2
change-id: 20250408-uio-dma-9b011e9e7f0b

Best regards,
-- 
Bastien Curutchet <bastien.curutchet@bootlin.com>

[PATCH 1/3] dma-buf: Allow heap that doesn't provide map_buf/unmap_buf

[Bastien Curutchet]

dma_buf_export() rejects the creation of dma_buf that don't implement
the map/unmap_buf operations while these operations aren't needed if the
buffer isn't shared by the user.

Allow dma_buf to be created even if these operations aren't implemented.
Add a check of their existence before using them.

Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
---
 drivers/dma-buf/dma-buf.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5baa83b855156516a0a766bee0789b122473efb3..398418bd9731ad7a3a1f12eaea6a155fa77a22fe 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -631,8 +631,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
 	int ret;
 
 	if (WARN_ON(!exp_info->priv || !exp_info->ops
-		    || !exp_info->ops->map_dma_buf
-		    || !exp_info->ops->unmap_dma_buf
 		    || !exp_info->ops->release))
 		return ERR_PTR(-EINVAL);
 
@@ -796,6 +794,9 @@ static struct sg_table *__map_dma_buf(struct dma_buf_attachment *attach,
 	struct sg_table *sg_table;
 	signed long ret;
 
+	if (!attach->dmabuf->ops->map_dma_buf)
+		return ERR_PTR(-EINVAL);
+
 	sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
 	if (IS_ERR_OR_NULL(sg_table))
 		return sg_table;
@@ -1002,7 +1003,8 @@ static void __unmap_dma_buf(struct dma_buf_attachment *attach,
 	/* uses XOR, hence this unmangles */
 	mangle_sg_table(sg_table);
 
-	attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
+	if (attach->dmabuf->ops->unmap_dma_buf)
+		attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
 }
 
 /**

-- 
2.49.0

[PATCH 2/3] dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR

[Bastien Curutchet]

There is no way to transmit the DMA address of a buffer to userspace.
Some UIO users need this to handle DMA from userspace.

Add a new dma_buf_ops operation that returns the DMA address.
Add a new ioctl to transmit this DMA address to userspace.

Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
---
 drivers/dma-buf/dma-buf.c    | 21 +++++++++++++++++++++
 include/linux/dma-buf.h      |  1 +
 include/uapi/linux/dma-buf.h |  1 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 398418bd9731ad7a3a1f12eaea6a155fa77a22fe..cbbb518981e54e50f479c3d1fcf6da6971f639c1 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -454,6 +454,24 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
 }
 #endif
 
+static int dma_buf_get_dma_addr(struct dma_buf *dmabuf, u64 __user *arg)
+{
+	u64 addr;
+	int ret;
+
+	if (!dmabuf->ops->get_dma_addr)
+		return -EINVAL;
+
+	ret = dmabuf->ops->get_dma_addr(dmabuf, &addr);
+	if (ret)
+		return ret;
+
+	if (copy_to_user(arg, &addr, sizeof(u64)))
+		return -EFAULT;
+
+	return 0;
+}
+
 static long dma_buf_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long arg)
 {
@@ -504,6 +522,9 @@ static long dma_buf_ioctl(struct file *file,
 		return dma_buf_import_sync_file(dmabuf, (const void __user *)arg);
 #endif
 
+	case DMA_BUF_IOCTL_GET_DMA_ADDR:
+		return dma_buf_get_dma_addr(dmabuf, (u64 __user *)arg);
+
 	default:
 		return -ENOTTY;
 	}
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 36216d28d8bdc01a9c9c47e27c392413f7f6c5fb..ed4bf15d3ce82e7a86323fff459699a9bc8baa3b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -285,6 +285,7 @@ struct dma_buf_ops {
 
 	int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map);
 	void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map *map);
+	int (*get_dma_addr)(struct dma_buf *dmabuf, u64 *addr);
 };
 
 /**
diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
index 5a6fda66d9adf01438619e7e67fa69f0fec2d88d..f3aba46942042de6a2e3a4cca3eb3f87175e29c9 100644
--- a/include/uapi/linux/dma-buf.h
+++ b/include/uapi/linux/dma-buf.h
@@ -178,5 +178,6 @@ struct dma_buf_import_sync_file {
 #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
 #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file)
 #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file)
+#define DMA_BUF_IOCTL_GET_DMA_ADDR	_IOR(DMA_BUF_BASE, 4, __u64 *)
 
 #endif

-- 
2.49.0

Re: [PATCH 2/3] dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR

[Nicolas Dufresne]

Hi Bastien,

Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
> There is no way to transmit the DMA address of a buffer to userspace.
> Some UIO users need this to handle DMA from userspace.

To me this API is against all safe practice we've been pushing forward
and has no place in DMA_BUF API.

If this is fine for the UIO subsystem to pass around physicial
addresses, then make this part of the UIO device ioctl.

regards,
Nicolas

> 
> Add a new dma_buf_ops operation that returns the DMA address.
> Add a new ioctl to transmit this DMA address to userspace.
> 
> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> ---
>  drivers/dma-buf/dma-buf.c    | 21 +++++++++++++++++++++
>  include/linux/dma-buf.h      |  1 +
>  include/uapi/linux/dma-buf.h |  1 +
>  3 files changed, 23 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index
> 398418bd9731ad7a3a1f12eaea6a155fa77a22fe..cbbb518981e54e50f479c3d1fcf
> 6da6971f639c1 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -454,6 +454,24 @@ static long dma_buf_import_sync_file(struct
> dma_buf *dmabuf,
>  }
>  #endif
>  
> +static int dma_buf_get_dma_addr(struct dma_buf *dmabuf, u64 __user
> *arg)
> +{
> +	u64 addr;
> +	int ret;
> +
> +	if (!dmabuf->ops->get_dma_addr)
> +		return -EINVAL;
> +
> +	ret = dmabuf->ops->get_dma_addr(dmabuf, &addr);
> +	if (ret)
> +		return ret;
> +
> +	if (copy_to_user(arg, &addr, sizeof(u64)))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +
>  static long dma_buf_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long arg)
>  {
> @@ -504,6 +522,9 @@ static long dma_buf_ioctl(struct file *file,
>  		return dma_buf_import_sync_file(dmabuf, (const void
> __user *)arg);
>  #endif
>  
> +	case DMA_BUF_IOCTL_GET_DMA_ADDR:
> +		return dma_buf_get_dma_addr(dmabuf, (u64 __user
> *)arg);
> +
>  	default:
>  		return -ENOTTY;
>  	}
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index
> 36216d28d8bdc01a9c9c47e27c392413f7f6c5fb..ed4bf15d3ce82e7a86323fff459
> 699a9bc8baa3b 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -285,6 +285,7 @@ struct dma_buf_ops {
>  
>  	int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map);
>  	void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map
> *map);
> +	int (*get_dma_addr)(struct dma_buf *dmabuf, u64 *addr);
>  };
>  
>  /**
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-
> buf.h
> index
> 5a6fda66d9adf01438619e7e67fa69f0fec2d88d..f3aba46942042de6a2e3a4cca3e
> b3f87175e29c9 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -178,5 +178,6 @@ struct dma_buf_import_sync_file {
>  #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
>  #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2,
> struct dma_buf_export_sync_file)
>  #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct
> dma_buf_import_sync_file)
> +#define DMA_BUF_IOCTL_GET_DMA_ADDR	_IOR(DMA_BUF_BASE, 4, __u64
> *)
>  
>  #endif

Re: [PATCH 2/3] dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR

[Simona Vetter]

Catching up after spring break, hence the late reply ...

On Fri, Apr 11, 2025 at 02:34:37PM -0400, Nicolas Dufresne wrote:
> Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
> > There is no way to transmit the DMA address of a buffer to userspace.
> > Some UIO users need this to handle DMA from userspace.
> 
> To me this API is against all safe practice we've been pushing forward
> and has no place in DMA_BUF API.
> 
> If this is fine for the UIO subsystem to pass around physicial
> addresses, then make this part of the UIO device ioctl.

Yeah, this has no business in dma-buf since the entire point of dma-buf
was to stop all the nasty "just pass raw dma addr in userspace" hacks that
preceeded it.

And over the years since dma-buf landed, we've removed a lot of these,
like dri1 drivers. Or where that's not possible like with fbdev, hid the
raw dma addr uapi behind a Kconfig.

I concur with the overall sentiment that this should be done in
vfio/iommufd interfaces, maybe with some support added to map dma-buf. I
think patches for that have been floating around for a while, but I lost a
bit the status of where exactly they are.

Cheers, Sima

> 
> regards,
> Nicolas
> 
> > 
> > Add a new dma_buf_ops operation that returns the DMA address.
> > Add a new ioctl to transmit this DMA address to userspace.
> > 
> > Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> > ---
> >  drivers/dma-buf/dma-buf.c    | 21 +++++++++++++++++++++
> >  include/linux/dma-buf.h      |  1 +
> >  include/uapi/linux/dma-buf.h |  1 +
> >  3 files changed, 23 insertions(+)
> > 
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index
> > 398418bd9731ad7a3a1f12eaea6a155fa77a22fe..cbbb518981e54e50f479c3d1fcf
> > 6da6971f639c1 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -454,6 +454,24 @@ static long dma_buf_import_sync_file(struct
> > dma_buf *dmabuf,
> >  }
> >  #endif
> >  
> > +static int dma_buf_get_dma_addr(struct dma_buf *dmabuf, u64 __user
> > *arg)
> > +{
> > +	u64 addr;
> > +	int ret;
> > +
> > +	if (!dmabuf->ops->get_dma_addr)
> > +		return -EINVAL;
> > +
> > +	ret = dmabuf->ops->get_dma_addr(dmabuf, &addr);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (copy_to_user(arg, &addr, sizeof(u64)))
> > +		return -EFAULT;
> > +
> > +	return 0;
> > +}
> > +
> >  static long dma_buf_ioctl(struct file *file,
> >  			  unsigned int cmd, unsigned long arg)
> >  {
> > @@ -504,6 +522,9 @@ static long dma_buf_ioctl(struct file *file,
> >  		return dma_buf_import_sync_file(dmabuf, (const void
> > __user *)arg);
> >  #endif
> >  
> > +	case DMA_BUF_IOCTL_GET_DMA_ADDR:
> > +		return dma_buf_get_dma_addr(dmabuf, (u64 __user
> > *)arg);
> > +
> >  	default:
> >  		return -ENOTTY;
> >  	}
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index
> > 36216d28d8bdc01a9c9c47e27c392413f7f6c5fb..ed4bf15d3ce82e7a86323fff459
> > 699a9bc8baa3b 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -285,6 +285,7 @@ struct dma_buf_ops {
> >  
> >  	int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map);
> >  	void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map
> > *map);
> > +	int (*get_dma_addr)(struct dma_buf *dmabuf, u64 *addr);
> >  };
> >  
> >  /**
> > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-
> > buf.h
> > index
> > 5a6fda66d9adf01438619e7e67fa69f0fec2d88d..f3aba46942042de6a2e3a4cca3e
> > b3f87175e29c9 100644
> > --- a/include/uapi/linux/dma-buf.h
> > +++ b/include/uapi/linux/dma-buf.h
> > @@ -178,5 +178,6 @@ struct dma_buf_import_sync_file {
> >  #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
> >  #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2,
> > struct dma_buf_export_sync_file)
> >  #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct
> > dma_buf_import_sync_file)
> > +#define DMA_BUF_IOCTL_GET_DMA_ADDR	_IOR(DMA_BUF_BASE, 4, __u64
> > *)
> >  
> >  #endif

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/3] dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR

[Christian König]

On 4/29/25 08:39, Simona Vetter wrote:
> Catching up after spring break, hence the late reply ...
> 
> On Fri, Apr 11, 2025 at 02:34:37PM -0400, Nicolas Dufresne wrote:
>> Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
>>> There is no way to transmit the DMA address of a buffer to userspace.
>>> Some UIO users need this to handle DMA from userspace.
>>
>> To me this API is against all safe practice we've been pushing forward
>> and has no place in DMA_BUF API.
>>
>> If this is fine for the UIO subsystem to pass around physicial
>> addresses, then make this part of the UIO device ioctl.
> 
> Yeah, this has no business in dma-buf since the entire point of dma-buf
> was to stop all the nasty "just pass raw dma addr in userspace" hacks that
> preceeded it.
> 
> And over the years since dma-buf landed, we've removed a lot of these,
> like dri1 drivers. Or where that's not possible like with fbdev, hid the
> raw dma addr uapi behind a Kconfig.
> 
> I concur with the overall sentiment that this should be done in
> vfio/iommufd interfaces, maybe with some support added to map dma-buf. I
> think patches for that have been floating around for a while, but I lost a
> bit the status of where exactly they are.

My take away is that we need to have a documented way for special driver specific interfaces in DMA-buf.

In other words DMA-buf has some standardized rules of doing things which every implementation should follow. The implementations might of course still have bugs (e.g. allocate memory for a dma_fence operation), but at least we have documented what should be done and what's forbidden.

What is still missing in the documentation is the use case when you have for example vfio which wants to talk to iommufd through a specialized interface. This doesn't necessarily needs to be part of DMA-buf, but we should still document "do it this way" because that has already worked in the last ten use cases and we don't want people to re-invent the wheel in a new funky way which then later turns out to not work.

Regards,
Christian.

> 
> Cheers, Sima
> 
>>
>> regards,
>> Nicolas
>>
>>>
>>> Add a new dma_buf_ops operation that returns the DMA address.
>>> Add a new ioctl to transmit this DMA address to userspace.
>>>
>>> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
>>> ---
>>>  drivers/dma-buf/dma-buf.c    | 21 +++++++++++++++++++++
>>>  include/linux/dma-buf.h      |  1 +
>>>  include/uapi/linux/dma-buf.h |  1 +
>>>  3 files changed, 23 insertions(+)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index
>>> 398418bd9731ad7a3a1f12eaea6a155fa77a22fe..cbbb518981e54e50f479c3d1fcf
>>> 6da6971f639c1 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -454,6 +454,24 @@ static long dma_buf_import_sync_file(struct
>>> dma_buf *dmabuf,
>>>  }
>>>  #endif
>>>  
>>> +static int dma_buf_get_dma_addr(struct dma_buf *dmabuf, u64 __user
>>> *arg)
>>> +{
>>> +	u64 addr;
>>> +	int ret;
>>> +
>>> +	if (!dmabuf->ops->get_dma_addr)
>>> +		return -EINVAL;
>>> +
>>> +	ret = dmabuf->ops->get_dma_addr(dmabuf, &addr);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	if (copy_to_user(arg, &addr, sizeof(u64)))
>>> +		return -EFAULT;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>>  static long dma_buf_ioctl(struct file *file,
>>>  			  unsigned int cmd, unsigned long arg)
>>>  {
>>> @@ -504,6 +522,9 @@ static long dma_buf_ioctl(struct file *file,
>>>  		return dma_buf_import_sync_file(dmabuf, (const void
>>> __user *)arg);
>>>  #endif
>>>  
>>> +	case DMA_BUF_IOCTL_GET_DMA_ADDR:
>>> +		return dma_buf_get_dma_addr(dmabuf, (u64 __user
>>> *)arg);
>>> +
>>>  	default:
>>>  		return -ENOTTY;
>>>  	}
>>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>>> index
>>> 36216d28d8bdc01a9c9c47e27c392413f7f6c5fb..ed4bf15d3ce82e7a86323fff459
>>> 699a9bc8baa3b 100644
>>> --- a/include/linux/dma-buf.h
>>> +++ b/include/linux/dma-buf.h
>>> @@ -285,6 +285,7 @@ struct dma_buf_ops {
>>>  
>>>  	int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map);
>>>  	void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map
>>> *map);
>>> +	int (*get_dma_addr)(struct dma_buf *dmabuf, u64 *addr);
>>>  };
>>>  
>>>  /**
>>> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-
>>> buf.h
>>> index
>>> 5a6fda66d9adf01438619e7e67fa69f0fec2d88d..f3aba46942042de6a2e3a4cca3e
>>> b3f87175e29c9 100644
>>> --- a/include/uapi/linux/dma-buf.h
>>> +++ b/include/uapi/linux/dma-buf.h
>>> @@ -178,5 +178,6 @@ struct dma_buf_import_sync_file {
>>>  #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
>>>  #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2,
>>> struct dma_buf_export_sync_file)
>>>  #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct
>>> dma_buf_import_sync_file)
>>> +#define DMA_BUF_IOCTL_GET_DMA_ADDR	_IOR(DMA_BUF_BASE, 4, __u64
>>> *)
>>>  
>>>  #endif
> 

[PATCH 3/3] uio: Add UIO_DMABUF_HEAP

[Bastien Curutchet]

Some UIO users need to access DMA addresses from userspace to be able to
configure DMA done by the UIO device. Currently there is no way of doing
this.

Add a UIO_DMABUF_HEAP Kconfig option. When selected, a dma-heap
allocator is created for every new UIO device. This allocator only
implements 4 basic operations: allocate, release, mmap and get_dma_addr.
The buffer allocation is done through dma_alloc_coherent().

Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
---
 drivers/uio/Kconfig        |   9 ++++
 drivers/uio/Makefile       |   1 +
 drivers/uio/uio.c          |   4 ++
 drivers/uio/uio_heap.c     | 120 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/uio_driver.h |   2 +
 5 files changed, 136 insertions(+)

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c6350191726c0830a1ae7b9a388ca4bb..2f3b1e57fceb01354b65cc4d39f342f645a238db 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -164,4 +164,13 @@ config UIO_DFL
 	    opae-sdk/tools/libopaeuio/
 
 	  If you compile this as a module, it will be called uio_dfl.
+
+config UIO_DMABUF_HEAP
+	bool "DMA-BUF UIO Heap"
+	select DMABUF_HEAPS
+	help
+	  Choose this option to enable DMA-BUF UIO heap. It will create a new
+	  heap allocator under /dev/dma_heap/ for every UIO device. This
+	  allocator allows userspace applications to allocate DMA buffers and
+	  access their DMA addresses thanks to the DMA_BUF_IOCTL_GET_DMA_HANDLE
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 1c5f3b5a95cf5b681a843b745a046d7ce123255d..f6696daa36567a4e5d18b1b89ba688057e758400 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_MF624)         += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)	+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)	+= uio_hv_generic.o
 obj-$(CONFIG_UIO_DFL)	+= uio_dfl.o
+obj-$(CONFIG_UIO_DMABUF_HEAP) += uio_heap.o
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index d93ed4e86a174b5bad193a61aa522cd833fe7bb5..f31936a897805a284165cccfee3d66e96acd4b39 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -1046,7 +1046,11 @@ int __uio_register_device(struct module *owner,
 		}
 	}
 
+#if defined(CONFIG_UIO_DMABUF_HEAP)
+	return add_uio_heap(idev);
+#else
 	return 0;
+#endif
 
 err_request_irq:
 	uio_dev_del_attributes(idev);
diff --git a/drivers/uio/uio_heap.c b/drivers/uio/uio_heap.c
new file mode 100644
index 0000000000000000000000000000000000000000..2e836b503458e280babba0e0adc4f6d8344efc82
--- /dev/null
+++ b/drivers/uio/uio_heap.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/dma-buf.h>
+#include <linux/dma-heap.h>
+#include <linux/uio_driver.h>
+
+struct uio_heap {
+	struct dma_heap *heap;
+	struct device *dev;
+};
+
+struct uio_heap_buffer {
+	struct uio_heap *heap;
+	dma_addr_t dma_addr;
+	unsigned long len;
+	void *vaddr;
+};
+
+static int uio_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+	struct uio_heap_buffer *buffer = dmabuf->priv;
+
+	return dma_mmap_coherent(buffer->heap->dev, vma, buffer->vaddr,
+				 buffer->dma_addr, buffer->len);
+}
+
+static void uio_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+	struct uio_heap_buffer *buffer = dmabuf->priv;
+
+	dma_free_coherent(buffer->heap->dev, buffer->len, buffer->vaddr,
+			  buffer->dma_addr);
+	kfree(buffer);
+}
+
+static int uio_heap_get_dma_addr(struct dma_buf *dmabuf, u64 *addr)
+{
+	struct uio_heap_buffer *buffer = dmabuf->priv;
+
+	*addr = buffer->dma_addr;
+	return 0;
+}
+
+static const struct dma_buf_ops uio_heap_buf_ops = {
+	.mmap = uio_heap_mmap,
+	.release = uio_heap_dma_buf_release,
+	.get_dma_addr = uio_heap_get_dma_addr,
+};
+
+static struct dma_buf *uio_heap_allocate(struct dma_heap *heap,
+					 unsigned long len,
+					 u32 fd_flags,
+					 u64 heap_flags)
+{
+	struct uio_heap *uio_heap = dma_heap_get_drvdata(heap);
+	DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+	struct uio_heap_buffer *buffer;
+	struct dma_buf *dmabuf;
+
+	buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
+	if (!buffer)
+		return ERR_PTR(-ENOMEM);
+
+	dma_set_coherent_mask(uio_heap->dev, DMA_BIT_MASK(32));
+
+	buffer->heap = uio_heap;
+	buffer->len = len;
+	buffer->vaddr = dma_alloc_coherent(uio_heap->dev, buffer->len,
+					   &buffer->dma_addr, GFP_KERNEL);
+	if (IS_ERR(buffer->vaddr))
+		goto free_buf;
+
+	exp_info.exp_name = dma_heap_get_name(heap);
+	exp_info.ops = &uio_heap_buf_ops;
+	exp_info.size = buffer->len;
+	exp_info.flags = fd_flags;
+	exp_info.priv = buffer;
+	dmabuf = dma_buf_export(&exp_info);
+	if (IS_ERR(dmabuf))
+		goto free_dma;
+
+	return dmabuf;
+
+free_dma:
+	dma_free_coherent(uio_heap->dev, buffer->len, buffer->vaddr, buffer->dma_addr);
+free_buf:
+	kfree(buffer);
+
+	return ERR_PTR(-ENOMEM);
+}
+
+static const struct dma_heap_ops uio_heap_ops = {
+	.allocate = uio_heap_allocate,
+};
+
+int add_uio_heap(struct uio_device *uio)
+{
+	struct dma_heap_export_info exp_info;
+	struct uio_heap *uio_heap;
+
+	uio_heap = kzalloc(sizeof(*uio_heap), GFP_KERNEL);
+	if (!uio_heap)
+		return -ENOMEM;
+
+	uio_heap->dev = &uio->dev;
+
+	/* Use device name as heap name */
+	exp_info.name = uio_heap->dev->kobj.name;
+	exp_info.ops = &uio_heap_ops;
+	exp_info.priv = uio_heap;
+
+	uio_heap->heap = dma_heap_add(&exp_info);
+	if (IS_ERR(uio_heap->heap)) {
+		int ret = PTR_ERR(uio_heap->heap);
+
+		kfree(uio_heap);
+		return ret;
+	}
+
+	return 0;
+}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 18238dc8bfd356a20996ba6cd84f1ff508bbb81c..f8b774d2fa1c7de4b6af881f1e53dfa9f25b3dbf 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -143,6 +143,8 @@ extern int __must_check
 				   struct device *parent,
 				   struct uio_info *info);
 
+extern int add_uio_heap(struct uio_device *uio);
+
 /* use a define to avoid include chaining to get THIS_MODULE */
 
 /**

-- 
2.49.0

Re: [PATCH 3/3] uio: Add UIO_DMABUF_HEAP

[Nicolas Dufresne]

Hi Bastien,

Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
> Some UIO users need to access DMA addresses from userspace to be able to
> configure DMA done by the UIO device. Currently there is no way of doing
> this.
> 
> Add a UIO_DMABUF_HEAP Kconfig option. When selected, a dma-heap
> allocator is created for every new UIO device. This allocator only
> implements 4 basic operations: allocate, release, mmap and get_dma_addr.
> The buffer allocation is done through dma_alloc_coherent().

This is quite redundant with the CMA heap. I believe a better design is
to make UIO devices dmabuf importers. This will make your UIO dmabuf
implementation a lot more useful.

As for the physical addresses, everywhere you currently pass a physical
address, you should be able to add ioctl to pass a DMABuf FD, or a
handle to an UIO specific object (similar to buffer objects in DRM) and
hide these.

regards,
Nicolas

> 
> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> ---
>  drivers/uio/Kconfig        |   9 ++++
>  drivers/uio/Makefile       |   1 +
>  drivers/uio/uio.c          |   4 ++
>  drivers/uio/uio_heap.c     | 120 +++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/uio_driver.h |   2 +
>  5 files changed, 136 insertions(+)
> 
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index b060dcd7c6350191726c0830a1ae7b9a388ca4bb..2f3b1e57fceb01354b65cc4d39f342f645a238db 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -164,4 +164,13 @@ config UIO_DFL
>  	    opae-sdk/tools/libopaeuio/
>  
>  	  If you compile this as a module, it will be called uio_dfl.
> +
> +config UIO_DMABUF_HEAP
> +	bool "DMA-BUF UIO Heap"
> +	select DMABUF_HEAPS
> +	help
> +	  Choose this option to enable DMA-BUF UIO heap. It will create a new
> +	  heap allocator under /dev/dma_heap/ for every UIO device. This
> +	  allocator allows userspace applications to allocate DMA buffers and
> +	  access their DMA addresses thanks to the DMA_BUF_IOCTL_GET_DMA_HANDLE
>  endif
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index 1c5f3b5a95cf5b681a843b745a046d7ce123255d..f6696daa36567a4e5d18b1b89ba688057e758400 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_MF624)         += uio_mf624.o
>  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)	+= uio_fsl_elbc_gpcm.o
>  obj-$(CONFIG_UIO_HV_GENERIC)	+= uio_hv_generic.o
>  obj-$(CONFIG_UIO_DFL)	+= uio_dfl.o
> +obj-$(CONFIG_UIO_DMABUF_HEAP) += uio_heap.o
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index d93ed4e86a174b5bad193a61aa522cd833fe7bb5..f31936a897805a284165cccfee3d66e96acd4b39 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -1046,7 +1046,11 @@ int __uio_register_device(struct module *owner,
>  		}
>  	}
>  
> +#if defined(CONFIG_UIO_DMABUF_HEAP)
> +	return add_uio_heap(idev);
> +#else
>  	return 0;
> +#endif
>  
>  err_request_irq:
>  	uio_dev_del_attributes(idev);
> diff --git a/drivers/uio/uio_heap.c b/drivers/uio/uio_heap.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..2e836b503458e280babba0e0adc4f6d8344efc82
> --- /dev/null
> +++ b/drivers/uio/uio_heap.c
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/dma-buf.h>
> +#include <linux/dma-heap.h>
> +#include <linux/uio_driver.h>
> +
> +struct uio_heap {
> +	struct dma_heap *heap;
> +	struct device *dev;
> +};
> +
> +struct uio_heap_buffer {
> +	struct uio_heap *heap;
> +	dma_addr_t dma_addr;
> +	unsigned long len;
> +	void *vaddr;
> +};
> +
> +static int uio_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> +{
> +	struct uio_heap_buffer *buffer = dmabuf->priv;
> +
> +	return dma_mmap_coherent(buffer->heap->dev, vma, buffer->vaddr,
> +				 buffer->dma_addr, buffer->len);
> +}
> +
> +static void uio_heap_dma_buf_release(struct dma_buf *dmabuf)
> +{
> +	struct uio_heap_buffer *buffer = dmabuf->priv;
> +
> +	dma_free_coherent(buffer->heap->dev, buffer->len, buffer->vaddr,
> +			  buffer->dma_addr);
> +	kfree(buffer);
> +}
> +
> +static int uio_heap_get_dma_addr(struct dma_buf *dmabuf, u64 *addr)
> +{
> +	struct uio_heap_buffer *buffer = dmabuf->priv;
> +
> +	*addr = buffer->dma_addr;
> +	return 0;
> +}
> +
> +static const struct dma_buf_ops uio_heap_buf_ops = {
> +	.mmap = uio_heap_mmap,
> +	.release = uio_heap_dma_buf_release,
> +	.get_dma_addr = uio_heap_get_dma_addr,
> +};
> +
> +static struct dma_buf *uio_heap_allocate(struct dma_heap *heap,
> +					 unsigned long len,
> +					 u32 fd_flags,
> +					 u64 heap_flags)
> +{
> +	struct uio_heap *uio_heap = dma_heap_get_drvdata(heap);
> +	DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> +	struct uio_heap_buffer *buffer;
> +	struct dma_buf *dmabuf;
> +
> +	buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> +	if (!buffer)
> +		return ERR_PTR(-ENOMEM);
> +
> +	dma_set_coherent_mask(uio_heap->dev, DMA_BIT_MASK(32));
> +
> +	buffer->heap = uio_heap;
> +	buffer->len = len;
> +	buffer->vaddr = dma_alloc_coherent(uio_heap->dev, buffer->len,
> +					   &buffer->dma_addr, GFP_KERNEL);
> +	if (IS_ERR(buffer->vaddr))
> +		goto free_buf;
> +
> +	exp_info.exp_name = dma_heap_get_name(heap);
> +	exp_info.ops = &uio_heap_buf_ops;
> +	exp_info.size = buffer->len;
> +	exp_info.flags = fd_flags;
> +	exp_info.priv = buffer;
> +	dmabuf = dma_buf_export(&exp_info);
> +	if (IS_ERR(dmabuf))
> +		goto free_dma;
> +
> +	return dmabuf;
> +
> +free_dma:
> +	dma_free_coherent(uio_heap->dev, buffer->len, buffer->vaddr, buffer->dma_addr);
> +free_buf:
> +	kfree(buffer);
> +
> +	return ERR_PTR(-ENOMEM);
> +}
> +
> +static const struct dma_heap_ops uio_heap_ops = {
> +	.allocate = uio_heap_allocate,
> +};
> +
> +int add_uio_heap(struct uio_device *uio)
> +{
> +	struct dma_heap_export_info exp_info;
> +	struct uio_heap *uio_heap;
> +
> +	uio_heap = kzalloc(sizeof(*uio_heap), GFP_KERNEL);
> +	if (!uio_heap)
> +		return -ENOMEM;
> +
> +	uio_heap->dev = &uio->dev;
> +
> +	/* Use device name as heap name */
> +	exp_info.name = uio_heap->dev->kobj.name;
> +	exp_info.ops = &uio_heap_ops;
> +	exp_info.priv = uio_heap;
> +
> +	uio_heap->heap = dma_heap_add(&exp_info);
> +	if (IS_ERR(uio_heap->heap)) {
> +		int ret = PTR_ERR(uio_heap->heap);
> +
> +		kfree(uio_heap);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 18238dc8bfd356a20996ba6cd84f1ff508bbb81c..f8b774d2fa1c7de4b6af881f1e53dfa9f25b3dbf 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -143,6 +143,8 @@ extern int __must_check
>  				   struct device *parent,
>  				   struct uio_info *info);
>  
> +extern int add_uio_heap(struct uio_device *uio);
> +
>  /* use a define to avoid include chaining to get THIS_MODULE */
>  
>  /**

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

[Christian König]

Am 10.04.25 um 16:53 schrieb Bastien Curutchet:
> 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.

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 know DMA shouldn't be handled by userspace but, IMHO, since UIO
> drivers exist, it would be better if they offered a way of doing this.

Leaking DMA addresses to userspace is usually seen as quite some security hole, but on the other hand with UIO you don't have much other choice.

> This patch series use the dma-heap framework which already allows
> userspace to allocate DMA buffers. I tried to avoid 'polluting' the
> existing heaps to prevent inappropriate uses of this new feature by
> introducing a new UIO heap, which is the only one implementing this
> behavior.

Yeah, that won't fly at all.

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.

Regards,
Christian.

>
> PATCH 1 allows the creation of heaps that don't implement map/unmap_buf
> operations as UIO heap doesn't use them.
> PATCH 2 adds the DMA_BUF_IOCTL_GET_DMA_ADDR which transmits the DMA
> addresses to userspace.
> PATCH 3 implements the UIO heap.
>
> It has been tested with the uio_pci_generic driver on a PowerPC.
>
> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> ---
> Bastien Curutchet (3):
>       dma-buf: Allow heap that doesn't provide map_buf/unmap_buf
>       dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR
>       uio: Add UIO_DMABUF_HEAP
>
>  drivers/dma-buf/dma-buf.c    |  29 +++++++++--
>  drivers/uio/Kconfig          |   9 ++++
>  drivers/uio/Makefile         |   1 +
>  drivers/uio/uio.c            |   4 ++
>  drivers/uio/uio_heap.c       | 120 +++++++++++++++++++++++++++++++++++++++++++
>  include/linux/dma-buf.h      |   1 +
>  include/linux/uio_driver.h   |   2 +
>  include/uapi/linux/dma-buf.h |   1 +
>  8 files changed, 164 insertions(+), 3 deletions(-)
> ---
> base-commit: 5f13fa25acaa4f586aaed12efcf7436e004eeaf2
> change-id: 20250408-uio-dma-9b011e9e7f0b
>
> Best regards,

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

[Thomas Petazzoni]

Hello Christian,

Thanks for your feedback!

On Thu, 10 Apr 2025 18:29:12 +0200
Christian König <christian.koenig@amd.com> 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?


> 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?

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.

If you could clarify here as well, it would definitely help in
understanding the shortcomings/limitations.

Thanks a lot!

Thomas Petazzoni
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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@amd.com> 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

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

[Christian König]

Hi Bastien,

Am 11.04.25 um 10:14 schrieb 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@amd.com> 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.

Ah! Yeah that wasn't really clear from the description.

But anyway please note that when you want to create new UAPI you need to provide an open source user of it. E.g. link to a repository or something similar in the covert letter should do it.

>> 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.

I don't know the UIO interfaces that well, but that is pretty clearly an abuse of DMA-buf and won't fly at all.

If you want coherent memory for your device you should use dma_alloc_coherent() for that.

Regards,
Christian.

>
>
> Best regards,
> Bastien
>
>
>

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

[Thomas Petazzoni]

Hello Christian,

On Fri, 11 Apr 2025 14:41:56 +0200
Christian König <christian.koenig@amd.com> wrote:

> But anyway please note that when you want to create new UAPI you need
> to provide an open source user of it. E.g. link to a repository or
> something similar in the covert letter should do it.

Could you clarify what is the "reference" user-space user of UIO that
exists today?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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

[Christian König]

Am 14.04.25 um 10:17 schrieb Thomas Petazzoni:
> Hello Christian,
>
> On Fri, 11 Apr 2025 14:41:56 +0200
> Christian König <christian.koenig@amd.com> wrote:
>
>> But anyway please note that when you want to create new UAPI you need
>> to provide an open source user of it. E.g. link to a repository or
>> something similar in the covert letter should do it.
> Could you clarify what is the "reference" user-space user of UIO that
> exists today?

I honestly don't know. I have never looked into UIO before this patch set arrived.

What I mean is that the general rule to justify adding UAPI to the Linux kernel is that you need to have an open source user of that UAPI.

In other words for UIO this means that you *can't* do things like exposing some kernel functionality like DMA-buf through UIO and then write a binary only driver on top of it.

Regards,
Christian.

>
> Thomas

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

[Christoph Hellwig]

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.

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

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

[Thomas Petazzoni]

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
https://bootlin.com

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

[Christian König]

Am 14.04.25 um 10:24 schrieb Thomas Petazzoni:
> 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.

Maybe I should try to better explain the concern here. The question is "Where is the source code of your FPGA driver?".

I mean that you are trying to replace the out-of-tree solution is rather welcomed, but the out-of-tree solutions are out-of-tree because they don't fit with requirements to be added to the core Linux tree.

And one of those requirements is that you need to provide the source code of the userspace user of this interface, in this case here that is your FPGA driver. An MIT/X11 license is usually sufficient, GPL is of course seen as better and it must not be a toy application, but rather the real thing.

And that is what people usually don't want and that's why no in-tree solution exists for this.

Regards,
Christian.

>
> 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

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

[Thomas Petazzoni]

Hello Christian,

On Mon, 14 Apr 2025 11:11:48 +0200
Christian König <christian.koenig@amd.com> wrote:

> Maybe I should try to better explain the concern here. The question
> is "Where is the source code of your FPGA driver?".
> 
> I mean that you are trying to replace the out-of-tree solution is
> rather welcomed, but the out-of-tree solutions are out-of-tree
> because they don't fit with requirements to be added to the core
> Linux tree.
> 
> And one of those requirements is that you need to provide the source
> code of the userspace user of this interface, in this case here that
> is your FPGA driver. An MIT/X11 license is usually sufficient, GPL is
> of course seen as better and it must not be a toy application, but
> rather the real thing.

Where is this requirement for UIO? The UIO subsystem does not have such
a requirement, unlike indeed some other kernel subsystems such as DRM.

But the practical situation is different: for DRM it makes a lot of
sense to enforce having open-source code in user-space, as we want to
force GPU vendors to open their OpenGL/Vulkan implementations. However,
for UIO it makes little sense, because UIO is typically used to control
some super-specific FPGA IP blocks that are totally irrelevant outside
of the very specific product they are included in. Most likely if those
drivers were open-sourced and tried to be upstream they would be
rejected because their usefulness in the upstream kernel is basically
zero (but they would have an on-going maintenance effort for the whole
community).

> And that is what people usually don't want and that's why no in-tree
> solution exists for this.

And that doesn't make sense because UIO already exists, and allows to
achieve 95% of what people already need, to the exception of this DMA
issue.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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

[Christoph Hellwig]

On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
> What this patch series is about is to add new user-space interface to
> extend the existing UIO subsystem.

Which as I explained to you is fundamentally broken and unsafe.  If you
need to do DMA from userspae you need 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.

Then your driver design can't work and you need to replace it with a
proper in-kernel driver.

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

[Thomas Petazzoni]

Hello Christoph,

On Mon, 14 Apr 2025 04:24:21 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
> > What this patch series is about is to add new user-space interface to
> > extend the existing UIO subsystem.  
> 
> Which as I explained to you is fundamentally broken and unsafe.  If you
> need to do DMA from userspae you need to use vfio/iommufd.

I'm still unclear as to why it is more "broken and unsafe" than UIO
already is. As I already replied in this thread: UIO allows to remap
MMIO registers into a user-space application, which can then do
whatever it wants with the IP block behind those MMIO registers. If
this IP block supports DMA, it already means that _today_ with the
current UIO subsystem as it is, the user-space application can program
a DMA transfer to read/write to any location in memory.

Therefore, providing a way to cleanly allocate DMA buffers and get
their physical address will not make things any better or worse in
terms of safety.

The fact that it is reasonably safe is solely based on access control
to the UIO device, done using usual Unix permissions, and that is
already the case today.

> > 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.  
> 
> Then your driver design can't work and you need to replace it with a
> proper in-kernel driver.

See above: your point is moot because providing capabilities to
allocate a buffer and get its physical address so that a UIO-based
user-space application can do DMA transfer does not make things any
more unsafe than they already are.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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

[Andrew Davis]

On 4/14/25 6:48 AM, Thomas Petazzoni wrote:
> Hello Christoph,
> 
> On Mon, 14 Apr 2025 04:24:21 -0700
> Christoph Hellwig <hch@infradead.org> wrote:
> 
>> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
>>> What this patch series is about is to add new user-space interface to
>>> extend the existing UIO subsystem.
>>
>> Which as I explained to you is fundamentally broken and unsafe.  If you
>> need to do DMA from userspae you need to use vfio/iommufd.
> 
> I'm still unclear as to why it is more "broken and unsafe" than UIO
> already is. As I already replied in this thread: UIO allows to remap
> MMIO registers into a user-space application, which can then do
> whatever it wants with the IP block behind those MMIO registers. If
> this IP block supports DMA, it already means that _today_ with the
> current UIO subsystem as it is, the user-space application can program
> a DMA transfer to read/write to any location in memory.
> 
> Therefore, providing a way to cleanly allocate DMA buffers and get
> their physical address will not make things any better or worse in
> terms of safety.
> 
> The fact that it is reasonably safe is solely based on access control
> to the UIO device, done using usual Unix permissions, and that is
> already the case today.
> 
>>> 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.
>>
>> Then your driver design can't work and you need to replace it with a
>> proper in-kernel driver.
> 
> See above: your point is moot because providing capabilities to
> allocate a buffer and get its physical address so that a UIO-based
> user-space application can do DMA transfer does not make things any
> more unsafe than they already are.
> 

"UIO is a broken legacy mess, so let's add more broken things
to it as broken + broken => still broken, so no harm done", am I
getting that right?

If your FPGA IP can do DMA then you should not be using UIO in
the first place, see UIO docs:

> Please note that UIO is not an universal driver interface. Devices that
> are already handled well by other kernel subsystems (like networking or
> serial or USB) are no candidates for an UIO driver.

The DMA subsystem already handles DMA devices, so write a DMA driver.

Andrew

> Best regards,
> 
> Thomas

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

[Thomas Petazzoni]

Hello Andrew,

On Mon, 14 Apr 2025 12:08:44 -0500
Andrew Davis <afd@ti.com> wrote:

> "UIO is a broken legacy mess, so let's add more broken things
> to it as broken + broken => still broken, so no harm done", am I
> getting that right?

Who says UIO is a "broken legacy mess"? Only you says so. I don't see
any indication anywhere in the kernel tree suggesting that UIO is
considered a broken legacy mess.

Keep in mind that when you're running code as root, you can load a
kernel module, which can do anything on the system security-wise. So
letting UIO expose MMIO registers of devices to userspace applications
running as root is not any worse than that.

> If your FPGA IP can do DMA then you should not be using UIO in
> the first place, see UIO docs:
> 
> > Please note that UIO is not an universal driver interface. Devices that
> > are already handled well by other kernel subsystems (like networking or
> > serial or USB) are no candidates for an UIO driver.  
> 
> The DMA subsystem already handles DMA devices, so write a DMA driver.

My FPGA IP block is not a DMA controller that would fit the dmaengine
kernel subsystem. It's a weird custom device that doesn't fit in any
existing subsystem, and that happens to do "peripheral DMA" (i.e the IP
block is DMA-capable itself, without relying on a separate DMA
controller). So this (very valid) recommendation from the UIO
documentation doesn't apply to my device.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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

[Andrew Davis]

On 4/14/25 2:21 PM, Thomas Petazzoni wrote:
> Hello Andrew,
> 
> On Mon, 14 Apr 2025 12:08:44 -0500
> Andrew Davis <afd@ti.com> wrote:
> 
>> "UIO is a broken legacy mess, so let's add more broken things
>> to it as broken + broken => still broken, so no harm done", am I
>> getting that right?
> 
> Who says UIO is a "broken legacy mess"? Only you says so. I don't see
> any indication anywhere in the kernel tree suggesting that UIO is
> considered a broken legacy mess.
> 

I'm not saying that*, I'm pointing out your argument is that even
though what you are trying to do is broken and unsafe, it is okay to
do because it isn't any "more "broken and unsafe" than UIO already is."

*It is, but that is an argument to have outside of this thread :)

> Keep in mind that when you're running code as root, you can load a
> kernel module, which can do anything on the system security-wise. So
> letting UIO expose MMIO registers of devices to userspace applications
> running as root is not any worse than that.
> 

You can take your computer out back and shoot it too, but we shouldn't
encourage that either :) According to the original docs, UIO was created
to support "industrial I/O cards", think old one-off custom ISA cards by
vendors that had no intention of ever writing a proper driver and just
wanted to poke registers and wait on an IRQ.

IMHO we shouldn't be encouraging that, and trying to modernize UIO does just
that. It gives the impression that is how drivers should still be written.
If you setup your FPGA card to go blink an LED, sure UIO driver it is,
anything more complex, then writing a proper driver is the way to go.

>> If your FPGA IP can do DMA then you should not be using UIO in
>> the first place, see UIO docs:
>>
>>> Please note that UIO is not an universal driver interface. Devices that
>>> are already handled well by other kernel subsystems (like networking or
>>> serial or USB) are no candidates for an UIO driver.
>>
>> The DMA subsystem already handles DMA devices, so write a DMA driver.
> 
> My FPGA IP block is not a DMA controller that would fit the dmaengine
> kernel subsystem. It's a weird custom device that doesn't fit in any
> existing subsystem, and that happens to do "peripheral DMA" (i.e the IP
> block is DMA-capable itself, without relying on a separate DMA
> controller). So this (very valid) recommendation from the UIO
> documentation doesn't apply to my device.

Peripheral DMA is the much more common case, nothing new here. Could
you give a hint as to what this device does that doesn't fit *any*
current subsystem? Or are we talking a hypothetical device (which
for the sake of argument is a valid thing to say, I'm sure with an
FPGA card I could make something that doesn't fit any current
framework too). Just want to know if you are trying to solve a
specific issue or a generic issue here.

Andrew

> 
> Best regards,
> 
> Thomas

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

[Jason Gunthorpe]

On Mon, Apr 14, 2025 at 09:21:25PM +0200, Thomas Petazzoni wrote:

> > "UIO is a broken legacy mess, so let's add more broken things
> > to it as broken + broken => still broken, so no harm done", am I
> > getting that right?
> 
> Who says UIO is a "broken legacy mess"? Only you says so. I don't see
> any indication anywhere in the kernel tree suggesting that UIO is
> considered a broken legacy mess.

Explain what the difference is between UIO and VFIO, especially VFIO
no-iommu mode?

I've always understood that UIO is for very simple devices that cannot
do DMA. So it's very simple operating model and simple security work
fine.

IMHO, if the can use DMA it should use VFIO. If you have no iommu then
you should use the VFIO unsafe no-iommu path. It still provides a
solid framework.

As to this series, I have seen a number of requests to improve the
VFIO no-iommu path to allow working with the existing IOAS scheme to
register memory but to allow the kernel the return the no-iommu
DMAable address of the IOAS pinned memory. This would replace the
hacky use of mlock and /proc/XX/pagemap that people use today.

If that were done, could you use VFIO no-iommu?

> Keep in mind that when you're running code as root, you can load a
> kernel module, which can do anything on the system security-wise. So
> letting UIO expose MMIO registers of devices to userspace applications
> running as root is not any worse than that.

That isn't fully true.. UIO isn't fitting into the security model by
allowing DMA capable devices to be exposed without checking for
CAP_SYS_RAW_IO first.

Jason