Re: [v7] Add udmabuf misc device
On 09/14/2018 03:00 PM, Gerd Hoffmann wrote: On Fri, Sep 14, 2018 at 02:00:30PM +0200, Tomeu Vizoso wrote: On 09/14/2018 08:37 AM, Gerd Hoffmann wrote: Hi, Well, no. This is *not* about 3D, it's about software rendering, for example cairo doing its work for gtk apps. So the workflow would be along these lines: (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. Why not let clients keep allocating memory for buffers with memfd? The guest proxy would then create a virtio-gpu resource to wrap the shm pool memory. Should be workable too, with udmabuf in the guest. Allocate with memfd, turn into dmabuf using udmabuf, let the virtio-gpu guest driver import the thing so you have a virtio-gpu resource handle for it. I don't see why this is better than using virtio-gpu dumb buffers directly though. Because wl_shm clients are allocating memory with memfd already, so they would need to be modified so they allocate dumb buffers instead. In practice, that means only modifying gtk, qt and sdl. Cheers, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
On Fri, Sep 14, 2018 at 02:00:30PM +0200, Tomeu Vizoso wrote: > On 09/14/2018 08:37 AM, Gerd Hoffmann wrote: > >Hi, > > > > > > Well, no. This is *not* about 3D, it's about software rendering, for > > > > example cairo doing its work for gtk apps. So the workflow would be > > > > along these lines: > > > > > > > > (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. > > Why not let clients keep allocating memory for buffers with memfd? > > The guest proxy would then create a virtio-gpu resource to wrap the shm pool > memory. Should be workable too, with udmabuf in the guest. Allocate with memfd, turn into dmabuf using udmabuf, let the virtio-gpu guest driver import the thing so you have a virtio-gpu resource handle for it. I don't see why this is better than using virtio-gpu dumb buffers directly though. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
On 09/14/2018 08:37 AM, Gerd Hoffmann wrote: Hi, Well, no. This is *not* about 3D, it's about software rendering, for example cairo doing its work for gtk apps. So the workflow would be along these lines: (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. Why not let clients keep allocating memory for buffers with memfd? The guest proxy would then create a virtio-gpu resource to wrap the shm pool memory. The VMM would receive a number of physical addresses that can be used to create a dmabuf. The would place the new FD in the wayland protocol stream. (2) guest app passes the buffer to wayland guest proxy (which looks like a wayland server/compositor to the app, but it doesn't actually composite anything). (3) wayland guest proxy passes buffer handle to wayland host proxy. (4) qemu can then use the buffer handle to lookup the virtio-gpu buffer, then use udmabuf to create a host dma-buf for it. (5) host dma-buf can be passed to host wayland server for display, so guest app window shows up seamlessly on the host. Details of the wayland protocol proxying are not hashed out yet. Thanks for the clarification. With dumb buffers, I guess the host can use DRM_FORMAT_MOD_LINEAR when sending the udmabuf-created buffer to the display. Note there are certain cases where tiled buffers are map-able (Intel), and with some variation of virtio_gpu_resource_create_coherent, we could expose that to the guest. The coherent mapping (host-allocated resources into guest address space) is another thing which needs to be sorted out. That's the direction we're interested in going, though it looks like udmabuf is orthogonal to that. Yes, udmabuf is the other way around, guest allocates resources and we make them available as host dmabufs. What details on wayland protocol proxying still need to be worked out? That's one component of the ChromiumOS solution (virtio_wl) that hasn't been up-streamed yet. That method maps guest fds to host fds. Tomeu Vizoso (Cc'ed) was looking into using virtio-serial as wayland protocol transport between host and guest. With udmabuf we can use virtio-gpu drm objects to pass pixel buffers from guest to host, which is one important building block for that. The approach that was agreed by everybody was to add ioctls to virtio-gpu to send and receive protocol messages. The guest proxy would use those ioctls and the VMM would play as the host proxy and would use similar virtio commands. There's code for that already and someone else from Collabora is to retake the upstreaming effort at some point soon. Regards, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
Hi, > > Well, no. This is *not* about 3D, it's about software rendering, for > > example cairo doing its work for gtk apps. So the workflow would be > > along these lines: > > > > (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. > > (2) guest app passes the buffer to wayland guest proxy (which looks > > like a wayland server/compositor to the app, but it doesn't actually > > composite anything). > > (3) wayland guest proxy passes buffer handle to wayland host proxy. > > (4) qemu can then use the buffer handle to lookup the virtio-gpu > > buffer, then use udmabuf to create a host dma-buf for it. > > (5) host dma-buf can be passed to host wayland server for display, so > > guest app window shows up seamlessly on the host. > > > > Details of the wayland protocol proxying are not hashed out yet. > > Thanks for the clarification. With dumb buffers, I guess the host can > use DRM_FORMAT_MOD_LINEAR when sending the udmabuf-created buffer to > the display. Note there are certain cases where tiled buffers are > map-able (Intel), and with some variation of > virtio_gpu_resource_create_coherent, we could expose that to the > guest. The coherent mapping (host-allocated resources into guest address space) is another thing which needs to be sorted out. > That's the direction we're interested in going, though it > looks like udmabuf is orthogonal to that. Yes, udmabuf is the other way around, guest allocates resources and we make them available as host dmabufs. > What details on wayland protocol proxying still need to be worked out? > That's one component of the ChromiumOS solution (virtio_wl) that > hasn't been up-streamed yet. That method maps guest fds to host fds. Tomeu Vizoso (Cc'ed) was looking into using virtio-serial as wayland protocol transport between host and guest. With udmabuf we can use virtio-gpu drm objects to pass pixel buffers from guest to host, which is one important building block for that. Not sure what the current state is. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
On Wed, Sep 12, 2018 at 11:44 PM Gerd Hoffmann wrote: > > On Wed, Sep 12, 2018 at 08:24:00PM -0700, Gurchetan Singh wrote: > > On Wed, Sep 12, 2018 at 12:03 AM Yann Droneaud wrote: > > > > > > Hi, > > > > > > Le lundi 27 août 2018 à 11:34 +0200, Gerd Hoffmann a écrit : > > > > A driver to let userspace turn memfd regions into dma-bufs. > > > > > > > > Use case: Allows qemu create dmabufs for the vga framebuffer or > > > > virtio-gpu ressources. Then they can be passed around to display > > > > those guest things on the host. To spice client for classic full > > > > framebuffer display, and hopefully some day to wayland server for > > > > seamless guest window display. > > > > Something like this is definitely needed. I assume one flow will be: > > > > 1) guest compositor allocates a buffer using udmabuf > > 2) 3D driver imports the udmabuf and renders to it > > 3) qemu turns this udmabuf into a host dma-buf > > 4) host compositor displays this dma-buf > > Well, no. This is *not* about 3D, it's about software rendering, for > example cairo doing its work for gtk apps. So the workflow would be > along these lines: > > (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. > (2) guest app passes the buffer to wayland guest proxy (which looks > like a wayland server/compositor to the app, but it doesn't actually > composite anything). > (3) wayland guest proxy passes buffer handle to wayland host proxy. > (4) qemu can then use the buffer handle to lookup the virtio-gpu > buffer, then use udmabuf to create a host dma-buf for it. > (5) host dma-buf can be passed to host wayland server for display, so > guest app window shows up seamlessly on the host. > > Details of the wayland protocol proxying are not hashed out yet. Thanks for the clarification. With dumb buffers, I guess the host can use DRM_FORMAT_MOD_LINEAR when sending the udmabuf-created buffer to the display. Note there are certain cases where tiled buffers are map-able (Intel), and with some variation of virtio_gpu_resource_create_coherent, we could expose that to the guest. That's the direction we're interested in going, though it looks like udmabuf is orthogonal to that. What details on wayland protocol proxying still need to be worked out? That's one component of the ChromiumOS solution (virtio_wl) that hasn't been up-streamed yet. That method maps guest fds to host fds. > > In that case, how does the guest know about the host's stride / > > alignment restrictions? For example, x-tiling on Intel (good for > > display) needs to have a stride that's a multiple of 512 bytes. > > For 3D rendering (aka virgl) the workflow is quite different. The guest > submits the rendering commands to the host, so the actual rendering > happens on the host gpu, to a host-allocated drm buffer. Which can be > exported as dma-buf by the gpu driver just fine. > > The guest passes resources needed for rendering (textures, ...) to the > host. I'm not sure how useful udmabuf is for that, exactly because of > the gpu specific formats. It's a tradeoff: On the plus side we can > avoid allocating a host resource and copying the data, by creating and > importing a dma-buf instead. On the other hand the host can convert the > data while copying it over from the guest to a host drm buffer, to a > format preferred by the host gpu (tiling, compressing, ...), so the gpu > will perform better that way. > > cheers, > Gerd > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
On Wed, Sep 12, 2018 at 08:24:00PM -0700, Gurchetan Singh wrote: > On Wed, Sep 12, 2018 at 12:03 AM Yann Droneaud wrote: > > > > Hi, > > > > Le lundi 27 août 2018 à 11:34 +0200, Gerd Hoffmann a écrit : > > > A driver to let userspace turn memfd regions into dma-bufs. > > > > > > Use case: Allows qemu create dmabufs for the vga framebuffer or > > > virtio-gpu ressources. Then they can be passed around to display > > > those guest things on the host. To spice client for classic full > > > framebuffer display, and hopefully some day to wayland server for > > > seamless guest window display. > > Something like this is definitely needed. I assume one flow will be: > > 1) guest compositor allocates a buffer using udmabuf > 2) 3D driver imports the udmabuf and renders to it > 3) qemu turns this udmabuf into a host dma-buf > 4) host compositor displays this dma-buf Well, no. This is *not* about 3D, it's about software rendering, for example cairo doing its work for gtk apps. So the workflow would be along these lines: (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. (2) guest app passes the buffer to wayland guest proxy (which looks like a wayland server/compositor to the app, but it doesn't actually composite anything). (3) wayland guest proxy passes buffer handle to wayland host proxy. (4) qemu can then use the buffer handle to lookup the virtio-gpu buffer, then use udmabuf to create a host dma-buf for it. (5) host dma-buf can be passed to host wayland server for display, so guest app window shows up seamlessly on the host. Details of the wayland protocol proxying are not hashed out yet. > In that case, how does the guest know about the host's stride / > alignment restrictions? For example, x-tiling on Intel (good for > display) needs to have a stride that's a multiple of 512 bytes. For 3D rendering (aka virgl) the workflow is quite different. The guest submits the rendering commands to the host, so the actual rendering happens on the host gpu, to a host-allocated drm buffer. Which can be exported as dma-buf by the gpu driver just fine. The guest passes resources needed for rendering (textures, ...) to the host. I'm not sure how useful udmabuf is for that, exactly because of the gpu specific formats. It's a tradeoff: On the plus side we can avoid allocating a host resource and copying the data, by creating and importing a dma-buf instead. On the other hand the host can convert the data while copying it over from the guest to a host drm buffer, to a format preferred by the host gpu (tiling, compressing, ...), so the gpu will perform better that way. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
On Wed, Sep 12, 2018 at 12:03 AM Yann Droneaud wrote:
>
> Hi,
>
> Le lundi 27 août 2018 à 11:34 +0200, Gerd Hoffmann a écrit :
> > A driver to let userspace turn memfd regions into dma-bufs.
> >
> > Use case: Allows qemu create dmabufs for the vga framebuffer or
> > virtio-gpu ressources. Then they can be passed around to display
> > those guest things on the host. To spice client for classic full
> > framebuffer display, and hopefully some day to wayland server for
> > seamless guest window display.
Something like this is definitely needed. I assume one flow will be:
1) guest compositor allocates a buffer using udmabuf
2) 3D driver imports the udmabuf and renders to it
3) qemu turns this udmabuf into a host dma-buf
4) host compositor displays this dma-buf
In that case, how does the guest know about the host's stride /
alignment restrictions? For example, x-tiling on Intel (good for
display) needs to have a stride that's a multiple of 512 bytes.
> >
> > qemu test branch:
> > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
> >
> > Cc: David Airlie
> > Cc: Tomeu Vizoso
> > Cc: Laurent Pinchart
> > Cc: Daniel Vetter
> > Signed-off-by: Gerd Hoffmann
> > Acked-by: Daniel Vetter
> > ---
> > Documentation/ioctl/ioctl-number.txt | 1 +
> > include/uapi/linux/udmabuf.h | 33 +++
> > drivers/dma-buf/udmabuf.c | 287
> > ++
> > tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> > MAINTAINERS | 16 ++
> > drivers/dma-buf/Kconfig | 8 +
> > drivers/dma-buf/Makefile | 1 +
> > tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> > 8 files changed, 447 insertions(+)
> > create mode 100644 include/uapi/linux/udmabuf.h
> > create mode 100644 drivers/dma-buf/udmabuf.c
> > create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> > create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
> >
> > diff --git a/include/uapi/linux/udmabuf.h
> > b/include/uapi/linux/udmabuf.h
> > new file mode 100644
> > index 00..46b6532ed8
> > --- /dev/null
> > +++ b/include/uapi/linux/udmabuf.h
> > @@ -0,0 +1,33 @@
> > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > +#ifndef _UAPI_LINUX_UDMABUF_H
> > +#define _UAPI_LINUX_UDMABUF_H
> > +
> > +#include
> > +#include
> > +
> > +#define UDMABUF_FLAGS_CLOEXEC0x01
> > +
> > +struct udmabuf_create {
> > + __u32 memfd;
> > + __u32 flags;
> > + __u64 offset;
> > + __u64 size;
> > +};
> > +
> > +struct udmabuf_create_item {
> > + __u32 memfd;
> > + __u32 __pad;
> > + __u64 offset;
> > + __u64 size;
> > +};
> > +
> > +struct udmabuf_create_list {
> > + __u32 flags;
> > + __u32 count;
> > + struct udmabuf_create_item list[];
> > +};
> > +
> > +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> > +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct
> > udmabuf_create_list)
> > +
> > +#endif /* _UAPI_LINUX_UDMABUF_H */
> > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> > new file mode 100644
> > index 00..8e24204526
> > --- /dev/null
> > +++ b/drivers/dma-buf/udmabuf.c
> > +static long udmabuf_create(struct udmabuf_create_list *head,
> > +struct udmabuf_create_item *list)
> > +{
> > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> > + struct file *memfd = NULL;
> > + struct udmabuf *ubuf;
> > + struct dma_buf *buf;
> > + pgoff_t pgoff, pgcnt, pgidx, pgbuf;
> > + struct page *page;
> > + int seals, ret = -EINVAL;
> > + u32 i, flags;
> > +
> > + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL);
> > + if (!ubuf)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < head->count; i++) {
>
> You need to check .__pad for unsupported value:
>
> if (list[i].__pad) {
> ret = -EINVAL;
> goto err_free_ubuf;
> }
>
> > + if (!IS_ALIGNED(list[i].offset, PAGE_SIZE))
> > + goto err_free_ubuf;
> > + if (!IS_ALIGNED(list[i].size, PAGE_SIZE))
> > + goto err_free_ubuf;
> > + ubuf->pagecount += list[i].size >> PAGE_SHIFT;
> > + }
> > + ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(struct page
> > *),
> > + GFP_KERNEL);
> > + if (!ubuf->pages) {
> > + ret = -ENOMEM;
> > + goto err_free_ubuf;
> > + }
> > +
> > + pgbuf = 0;
> > + for (i = 0; i < head->count; i++) {
> > + memfd = fget(list[i].memfd);
> > + if (!memfd)
> > + goto err_put_pages;
> > + if (!shmem_mapping(file_inode(memfd)->i_mapping))
> > + goto err_put_pages;
> > + seals = memfd_fcntl(memfd,
Re: [v7] Add udmabuf misc device
Hi,
Le lundi 27 août 2018 à 11:34 +0200, Gerd Hoffmann a écrit :
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> Acked-by: Daniel Vetter
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/uapi/linux/udmabuf.h | 33 +++
> drivers/dma-buf/udmabuf.c | 287
> ++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> MAINTAINERS | 16 ++
> drivers/dma-buf/Kconfig | 8 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 8 files changed, 447 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
>
> diff --git a/include/uapi/linux/udmabuf.h
> b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..46b6532ed8
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_item {
> + __u32 memfd;
> + __u32 __pad;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_list {
> + __u32 flags;
> + __u32 count;
> + struct udmabuf_create_item list[];
> +};
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct
> udmabuf_create_list)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..8e24204526
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> +static long udmabuf_create(struct udmabuf_create_list *head,
> +struct udmabuf_create_item *list)
> +{
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct file *memfd = NULL;
> + struct udmabuf *ubuf;
> + struct dma_buf *buf;
> + pgoff_t pgoff, pgcnt, pgidx, pgbuf;
> + struct page *page;
> + int seals, ret = -EINVAL;
> + u32 i, flags;
> +
> + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL);
> + if (!ubuf)
> + return -ENOMEM;
> +
> + for (i = 0; i < head->count; i++) {
You need to check .__pad for unsupported value:
if (list[i].__pad) {
ret = -EINVAL;
goto err_free_ubuf;
}
> + if (!IS_ALIGNED(list[i].offset, PAGE_SIZE))
> + goto err_free_ubuf;
> + if (!IS_ALIGNED(list[i].size, PAGE_SIZE))
> + goto err_free_ubuf;
> + ubuf->pagecount += list[i].size >> PAGE_SHIFT;
> + }
> + ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(struct page
> *),
> + GFP_KERNEL);
> + if (!ubuf->pages) {
> + ret = -ENOMEM;
> + goto err_free_ubuf;
> + }
> +
> + pgbuf = 0;
> + for (i = 0; i < head->count; i++) {
> + memfd = fget(list[i].memfd);
> + if (!memfd)
> + goto err_put_pages;
> + if (!shmem_mapping(file_inode(memfd)->i_mapping))
> + goto err_put_pages;
> + seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
> + if (seals == -EINVAL ||
> + (seals & SEALS_WANTED) != SEALS_WANTED ||
> + (seals & SEALS_DENIED) != 0)
> + goto err_put_pages;
> + pgoff = list[i].offset >> PAGE_SHIFT;
> + pgcnt = list[i].size >> PAGE_SHIFT;
> + for (pgidx = 0; pgidx < pgcnt; pgidx++) {
> + page = shmem_read_mapping_page(
> + file_inode(memfd)->i_mapping, pgoff +
> pgidx);
> + if (IS_ERR(page)) {
> + ret = PTR_ERR(page);
> + goto err_put_pages;
> + }
> + ubuf->pages[pgbuf++] = page;
> + }
> +
Re: [PATCH v7] Add udmabuf misc device
> > >> +if (WARN_ON(vmf->pgoff >= ubuf->pagecount)) > > >> +return VM_FAULT_SIGBUS; > > > > > > Just curious, when do you expect this to happen ? > > > > It should not. If it actually happens it would be a bug somewhere, > > thats why the WARN_ON. > > But you seem to consider that this condition that should never happen still > has a high enough chance of happening that it's worth a WARN_ON(). I was > wondering why this one in particular, and not other conditions that also > can't > happen and are not checked through the code. Added it while writing the code, to get any coding mistake I make flagged right away instead of things exploding later on. I can drop it. > > >> +ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL); > > > > > > sizeof(*ubuf) > > > > Why? Should not make a difference ... > > Because the day we replace > > struct udmabuf *ubuf; > > with > > struct udmabuf_ext *ubuf; > > and forget to change the next line, we'll introduce a bug. That's why > sizeof(variable) is preferred over sizeof(type). Another reason is that I can > easily see that > > ubuf = kzalloc(sizeof(*ubuf), GFP_KERNEL); > > is correct, while using sizeof(type) requires me to go and look up the > declaration of the variable. So it simplifies review, ok, will change it. BTW: Maybe the kernel should pick up a neat trick from glib: g_new0() is a macro which takes the type instead of the size as first argument, and it casts the return value to that type. So the compiler will throw warnings in case of a mismatch. That'll work better than depending purely on the coder being careful and review catching the remaining issues. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] Add udmabuf misc device
On Tue, Sep 11, 2018 at 11:50 AM, Laurent Pinchart
wrote:
> Hi Gerd,
>
> On Tuesday, 11 September 2018 09:50:14 EEST Gerd Hoffmann wrote:
>> Hi,
>>
>> >> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
>> >
>> > Why do you start at 0x42 if you reserve the 0x40-0x4f range ?
>>
>> No particular strong reason, just that using 42 was less boring than
>> starting with 0x40.
>>
>> >> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct
>> >> udmabuf_create_list)
>> >
>> > Where's the documentation ? :-)
>>
>> Isn't it simple enough?
>
> No kernel UAPI is simple enough to get away without documenting it.
Simplest option would be to throw a bit of kerneldoc into the uapi
header, add Documentation/driver-api/dma-buf.rst.
-Daniel
>
>> But, well, yes, I guess I can add some kerneldoc comments.
>>
>> >> +static int udmabuf_vm_fault(struct vm_fault *vmf)
>> >> +{
>> >> + struct vm_area_struct *vma = vmf->vma;
>> >> + struct udmabuf *ubuf = vma->vm_private_data;
>> >> +
>> >> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
>> >> + return VM_FAULT_SIGBUS;
>> >
>> > Just curious, when do you expect this to happen ?
>>
>> It should not. If it actually happens it would be a bug somewhere,
>> thats why the WARN_ON.
>
> But you seem to consider that this condition that should never happen still
> has a high enough chance of happening that it's worth a WARN_ON(). I was
> wondering why this one in particular, and not other conditions that also can't
> happen and are not checked through the code.
>
>> >> + struct udmabuf *ubuf;
>> >>
>> >> + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL);
>> >
>> > sizeof(*ubuf)
>>
>> Why? Should not make a difference ...
>
> Because the day we replace
>
> struct udmabuf *ubuf;
>
> with
>
> struct udmabuf_ext *ubuf;
>
> and forget to change the next line, we'll introduce a bug. That's why
> sizeof(variable) is preferred over sizeof(type). Another reason is that I can
> easily see that
>
> ubuf = kzalloc(sizeof(*ubuf), GFP_KERNEL);
>
> is correct, while using sizeof(type) requires me to go and look up the
> declaration of the variable.
>
>> >> + memfd = fget(list[i].memfd);
>> >> + if (!memfd)
>> >> + goto err_put_pages;
>> >> + if (!shmem_mapping(file_inode(memfd)->i_mapping))
>> >> + goto err_put_pages;
>> >> + seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
>> >> + if (seals == -EINVAL ||
>> >> + (seals & SEALS_WANTED) != SEALS_WANTED ||
>> >> + (seals & SEALS_DENIED) != 0)
>> >> + goto err_put_pages;
>> >
>> > All these conditions will return -EINVAL. I'm not familiar with the memfd
>> > API, should some error conditions return a different error code to make
>> > them distinguishable by userspace ?
>>
>> Hmm, I guess EBADFD would be reasonable in case the file handle isn't a
>> memfd. Other suggestions?
>
> I'll let others comment on this as I don't feel qualified to pick proper error
> codes, not being familiar with the memfd API.
>
>> I'll prepare a fixup patch series addressing most of the other
>> review comments.
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] Add udmabuf misc device
Hi Gerd,
On Tuesday, 11 September 2018 09:50:14 EEST Gerd Hoffmann wrote:
> Hi,
>
> >> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> >
> > Why do you start at 0x42 if you reserve the 0x40-0x4f range ?
>
> No particular strong reason, just that using 42 was less boring than
> starting with 0x40.
>
> >> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct
> >> udmabuf_create_list)
> >
> > Where's the documentation ? :-)
>
> Isn't it simple enough?
No kernel UAPI is simple enough to get away without documenting it.
> But, well, yes, I guess I can add some kerneldoc comments.
>
> >> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> >> +{
> >> + struct vm_area_struct *vma = vmf->vma;
> >> + struct udmabuf *ubuf = vma->vm_private_data;
> >> +
> >> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> >> + return VM_FAULT_SIGBUS;
> >
> > Just curious, when do you expect this to happen ?
>
> It should not. If it actually happens it would be a bug somewhere,
> thats why the WARN_ON.
But you seem to consider that this condition that should never happen still
has a high enough chance of happening that it's worth a WARN_ON(). I was
wondering why this one in particular, and not other conditions that also can't
happen and are not checked through the code.
> >> + struct udmabuf *ubuf;
> >>
> >> + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL);
> >
> > sizeof(*ubuf)
>
> Why? Should not make a difference ...
Because the day we replace
struct udmabuf *ubuf;
with
struct udmabuf_ext *ubuf;
and forget to change the next line, we'll introduce a bug. That's why
sizeof(variable) is preferred over sizeof(type). Another reason is that I can
easily see that
ubuf = kzalloc(sizeof(*ubuf), GFP_KERNEL);
is correct, while using sizeof(type) requires me to go and look up the
declaration of the variable.
> >> + memfd = fget(list[i].memfd);
> >> + if (!memfd)
> >> + goto err_put_pages;
> >> + if (!shmem_mapping(file_inode(memfd)->i_mapping))
> >> + goto err_put_pages;
> >> + seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
> >> + if (seals == -EINVAL ||
> >> + (seals & SEALS_WANTED) != SEALS_WANTED ||
> >> + (seals & SEALS_DENIED) != 0)
> >> + goto err_put_pages;
> >
> > All these conditions will return -EINVAL. I'm not familiar with the memfd
> > API, should some error conditions return a different error code to make
> > them distinguishable by userspace ?
>
> Hmm, I guess EBADFD would be reasonable in case the file handle isn't a
> memfd. Other suggestions?
I'll let others comment on this as I don't feel qualified to pick proper error
codes, not being familiar with the memfd API.
> I'll prepare a fixup patch series addressing most of the other
> review comments.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] Add udmabuf misc device
Hi,
> > +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
>
> Why do you start at 0x42 if you reserve the 0x40-0x4f range ?
No particular strong reason, just that using 42 was less boring than
starting with 0x40.
> > +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
>
> Where's the documentation ? :-)
Isn't it simple enough?
But, well, yes, I guess I can add some kerneldoc comments.
> > +static int udmabuf_vm_fault(struct vm_fault *vmf)
> > +{
> > + struct vm_area_struct *vma = vmf->vma;
> > + struct udmabuf *ubuf = vma->vm_private_data;
> > +
> > + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> > + return VM_FAULT_SIGBUS;
>
> Just curious, when do you expect this to happen ?
It should not. If it actually happens it would be a bug somewhere,
thats why the WARN_ON.
> > + struct udmabuf *ubuf;
> > + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL);
>
> sizeof(*ubuf)
Why? Should not make a difference ...
> > + memfd = fget(list[i].memfd);
> > + if (!memfd)
> > + goto err_put_pages;
> > + if (!shmem_mapping(file_inode(memfd)->i_mapping))
> > + goto err_put_pages;
> > + seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
> > + if (seals == -EINVAL ||
> > + (seals & SEALS_WANTED) != SEALS_WANTED ||
> > + (seals & SEALS_DENIED) != 0)
> > + goto err_put_pages;
>
> All these conditions will return -EINVAL. I'm not familiar with the memfd
> API,
> should some error conditions return a different error code to make them
> distinguishable by userspace ?
Hmm, I guess EBADFD would be reasonable in case the file handle isn't a
memfd. Other suggestions?
I'll prepare a fixup patch series addressing most of the other
review comments.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] Add udmabuf misc device
Hi Gerd,
Thank you for the patch.
CC'ing the linux-api mailing list as this creates a new userspace API.
On Monday, 27 August 2018 12:34:44 EEST Gerd Hoffmann wrote:
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/uapi/linux/udmabuf.h | 33 +++
> drivers/dma-buf/udmabuf.c | 287 +++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> MAINTAINERS | 16 ++
> drivers/dma-buf/Kconfig | 8 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 8 files changed, 447 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
[snip]
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..46b6532ed8
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_item {
> + __u32 memfd;
> + __u32 __pad;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_list {
> + __u32 flags;
> + __u32 count;
> + struct udmabuf_create_item list[];
> +};
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
Why do you start at 0x42 if you reserve the 0x40-0x4f range ?
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
Where's the documentation ? :-)
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..8e24204526
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Could you please keep the #include alphabetically sorted ? It helps locating
duplicates.
> +#include
I think you can just #include , no need to use the uapi/
prefix.
> +struct udmabuf {
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
Just curious, when do you expect this to happen ?
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
You can return ERR_PTR(-ENOMEM) directly.
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + GFP_KERNEL) < 0)
Shouldn't you propagate the return value from sg_alloc_table_from_pages() ?
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
> + goto err3;
> +
> + return sg;
> +
> +err3:
> + sg_free_table(sg);
> +err2:
> + kfree(sg);
> +err1:
> + return ERR_PTR(-ENOMEM);
You can merge
Re: [PATCH v7] Add udmabuf misc device
On Mon, Aug 27, 2018 at 11:34:44AM +0200, Gerd Hoffmann wrote:
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/uapi/linux/udmabuf.h | 33 +++
> drivers/dma-buf/udmabuf.c | 287
> ++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> MAINTAINERS | 16 ++
> drivers/dma-buf/Kconfig | 8 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 8 files changed, 447 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
>
> diff --git a/Documentation/ioctl/ioctl-number.txt
> b/Documentation/ioctl/ioctl-number.txt
> index 13a7c999c0..f2ac672eb7 100644
> --- a/Documentation/ioctl/ioctl-number.txt
> +++ b/Documentation/ioctl/ioctl-number.txt
> @@ -272,6 +272,7 @@ Code Seq#(hex) Include FileComments
> 't' 90-91 linux/toshiba.h toshiba and toshiba_acpi SMM
> 'u' 00-1F linux/smb_fs.h gone
> 'u' 20-3F linux/uvcvideo.hUSB video class host driver
> +'u' 40-4f linux/udmabuf.h userspace dma-buf misc device
> 'v' 00-1F linux/ext2_fs.h conflict!
> 'v' 00-1F linux/fs.h conflict!
> 'v' 00-0F linux/sonypi.h conflict!
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..46b6532ed8
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_item {
> + __u32 memfd;
> + __u32 __pad;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_list {
> + __u32 flags;
> + __u32 count;
> + struct udmabuf_create_item list[];
> +};
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..8e24204526
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct udmabuf {
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
> +
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + GFP_KERNEL) < 0)
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
>
[PATCH v7] Add udmabuf misc device
A driver to let userspace turn memfd regions into dma-bufs.
Use case: Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources. Then they can be passed around to display
those guest things on the host. To spice client for classic full
framebuffer display, and hopefully some day to wayland server for
seamless guest window display.
qemu test branch:
https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
Cc: David Airlie
Cc: Tomeu Vizoso
Cc: Laurent Pinchart
Cc: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
Documentation/ioctl/ioctl-number.txt | 1 +
include/uapi/linux/udmabuf.h | 33 +++
drivers/dma-buf/udmabuf.c | 287 ++
tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
MAINTAINERS | 16 ++
drivers/dma-buf/Kconfig | 8 +
drivers/dma-buf/Makefile | 1 +
tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
8 files changed, 447 insertions(+)
create mode 100644 include/uapi/linux/udmabuf.h
create mode 100644 drivers/dma-buf/udmabuf.c
create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 13a7c999c0..f2ac672eb7 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -272,6 +272,7 @@ Code Seq#(hex) Include FileComments
't'90-91 linux/toshiba.h toshiba and toshiba_acpi SMM
'u'00-1F linux/smb_fs.h gone
'u'20-3F linux/uvcvideo.hUSB video class host driver
+'u'40-4f linux/udmabuf.h userspace dma-buf misc device
'v'00-1F linux/ext2_fs.h conflict!
'v'00-1F linux/fs.h conflict!
'v'00-0F linux/sonypi.h conflict!
diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
new file mode 100644
index 00..46b6532ed8
--- /dev/null
+++ b/include/uapi/linux/udmabuf.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_UDMABUF_H
+#define _UAPI_LINUX_UDMABUF_H
+
+#include
+#include
+
+#define UDMABUF_FLAGS_CLOEXEC 0x01
+
+struct udmabuf_create {
+ __u32 memfd;
+ __u32 flags;
+ __u64 offset;
+ __u64 size;
+};
+
+struct udmabuf_create_item {
+ __u32 memfd;
+ __u32 __pad;
+ __u64 offset;
+ __u64 size;
+};
+
+struct udmabuf_create_list {
+ __u32 flags;
+ __u32 count;
+ struct udmabuf_create_item list[];
+};
+
+#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
+#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
+
+#endif /* _UAPI_LINUX_UDMABUF_H */
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
new file mode 100644
index 00..8e24204526
--- /dev/null
+++ b/drivers/dma-buf/udmabuf.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct udmabuf {
+ u32 pagecount;
+ struct page **pages;
+};
+
+static int udmabuf_vm_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct udmabuf *ubuf = vma->vm_private_data;
+
+ if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
+ return VM_FAULT_SIGBUS;
+
+ vmf->page = ubuf->pages[vmf->pgoff];
+ get_page(vmf->page);
+ return 0;
+}
+
+static const struct vm_operations_struct udmabuf_vm_ops = {
+ .fault = udmabuf_vm_fault,
+};
+
+static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+ struct udmabuf *ubuf = buf->priv;
+
+ if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
+ return -EINVAL;
+
+ vma->vm_ops = _vm_ops;
+ vma->vm_private_data = ubuf;
+ return 0;
+}
+
+static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
+ enum dma_data_direction direction)
+{
+ struct udmabuf *ubuf = at->dmabuf->priv;
+ struct sg_table *sg;
+
+ sg = kzalloc(sizeof(*sg), GFP_KERNEL);
+ if (!sg)
+ goto err1;
+ if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
+ 0, ubuf->pagecount << PAGE_SHIFT,
+ GFP_KERNEL) < 0)
+ goto err2;
+ if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
+ goto err3;
+
+ return sg;
+
+err3:
+ sg_free_table(sg);
+err2:
+ kfree(sg);
+err1:
+ return ERR_PTR(-ENOMEM);
+}
+
+static void unmap_udmabuf(struct dma_buf_attachment *at,
+ struct sg_table *sg,
+
