Re: [PATCH v6] Add udmabuf misc device
Hi, > > qemu can use memfd to allocate guest ram. Now, with the help of > > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > > buffer. > > Guess each physical address in the iovec in > VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING can be passed as the offset in the > udmabuf_create_item struct? Exactly. https://git.kraxel.org/cgit/qemu/commit/?h=sirius/udmabuf=515a5b9f1215ea668a992e39d66993a17a940801 > Are you thinking of anything else besides passing the winsrv protocol across > the guest/host boundary? Just wondering if I'm missing something. The patch above uses the dmabuf internally in qemu. It simply mmaps it, so qemu has a linear representation of the resource and can use it as pixman image backing storage without copying the pixel data. So it is useful even without actually exporting the dmabuf to other processes. cheers, Gerd PS: Any chance you can review the v7 patch? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On 07/04/2018 10:00 AM, Gerd Hoffmann wrote: On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: On Tue, Jul 03, 2018 at 09:53:58AM +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 I think some ack for a 2nd use-case, like virtio-wl or whatever would be really cool. To give us some assurance that this is generically useful. Tomeu? Laurent? Sorry, but I think I will need some help to understand how this could help in the virtio-wl case [adding Zach Reizner to CC]. Any graphics buffers that are allocated with memfd will be shared with the compositor via wl_shm, without need for dmabufs. Within one machine, yes. Once virtualization is added to the mix things become more complicated ... When using virtio-gpu the guest will allocate graphics buffers from normal (guest) ram, then register these buffers (which are allowed to be scattered) with the host as resource. qemu can use memfd to allocate guest ram. Now, with the help of udmabuf, qemu can create a *host* dma-buf for the *guest* graphics buffer. Guess each physical address in the iovec in VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING can be passed as the offset in the udmabuf_create_item struct? That dma-buf can be used by qemu internally (mmap it to get a linear mapping of the resource, to avoid copying). It can be passed on to spice-client, to display the guest framebuffer. And I think it could also be quite useful to pass guest wayland windows to the host compositor, without mapping host-allocated buffers into the guest, so we don't have do deal with the "find some address space for the mapping" issue in the first place. Sounds good to me if the answer to the above is "yes". There are more things needed to complete this of course, but it's a building block ... Are you thinking of anything else besides passing the winsrv protocol across the guest/host boundary? Just wondering if I'm missing something. Thanks, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
Hi, > > Covering udmabuf.c maintainance is a different issue. I could just add > > myself to the existing entry, or create a new one specifically for > > udmabuf. > > That's what I meant, do a more specific entry to add yourself just for > udmabuf. Ok. Back from summer vacation, finally found the time to continue working on this. Entry added, rebased to 4.19-rc1, v7 comes in a moment. Please review & ack. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On 4 July 2018 at 18:00, Gerd Hoffmann wrote: > On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: >> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: >> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: >> > > On Tue, Jul 03, 2018 at 09:53:58AM +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 >> > > >> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be >> > > really cool. To give us some assurance that this is generically useful. >> > >> > Tomeu? Laurent? >> >> Sorry, but I think I will need some help to understand how this could help >> in the virtio-wl case [adding Zach Reizner to CC]. >> >> Any graphics buffers that are allocated with memfd will be shared with the >> compositor via wl_shm, without need for dmabufs. > > Within one machine, yes. Once virtualization is added to the mix things > become more complicated ... > > When using virtio-gpu the guest will allocate graphics buffers from > normal (guest) ram, then register these buffers (which are allowed to be > scattered) with the host as resource. > > qemu can use memfd to allocate guest ram. Now, with the help of > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics > buffer. > > That dma-buf can be used by qemu internally (mmap it to get a linear > mapping of the resource, to avoid copying). It can be passed on to > spice-client, to display the guest framebuffer. > > And I think it could also be quite useful to pass guest wayland windows > to the host compositor, without mapping host-allocated buffers into the > guest, so we don't have do deal with the "find some address space for > the mapping" issue in the first place. There are more things needed to > complete this of course, but it's a building block ... There is a use case where I think we have to deal with the "find some address space" problem. For GL4.4 ARB_buffer_storage and Vulkan memory mangement there is the concept of coherent buffers between GPU and CPU. From the virgl point of view, we'd create a host buffer in GL, and then create a mapping from it on the host that we'd need to present in the guest userspace as a linear buffer. Just in case we think this can solve all our problems :-) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On Wed, Jul 04, 2018 at 10:58:25AM +0200, Gerd Hoffmann wrote: > Hi, > > > > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists > > > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. > > > > Yeah, maintainers entry with you as maintainer plus dri-devel as mailing > > list plus drm-misc as repo would be good. Just grep for drm-misc.git for > > tons of examples. > > There is an *existing* entry covering drivers/dma-buf/, and I've dropped > udmabuf.c into that directory, so I've assumed get_maintainers.pl picks > up all relevant dma-buf folks ... > > Covering udmabuf.c maintainance is a different issue. I could just add > myself to the existing entry, or create a new one specifically for > udmabuf. That's what I meant, do a more specific entry to add yourself just for udmabuf. > > > Who should be Cc'ed? > > > > dim add-missing-cc ftw :-) > > That just uses get_maintainer.pl according to the docs, so that wouldn't > change things as that is wired up as sendemail.cccmd already. Except > that dim would probably add the list of people to the commit message. Ah right, I totally missed that you have more on the mail's Cc: than on the patch. I never do that, so always miss them :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
Hi, > > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists > > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. > > Yeah, maintainers entry with you as maintainer plus dri-devel as mailing > list plus drm-misc as repo would be good. Just grep for drm-misc.git for > tons of examples. There is an *existing* entry covering drivers/dma-buf/, and I've dropped udmabuf.c into that directory, so I've assumed get_maintainers.pl picks up all relevant dma-buf folks ... Covering udmabuf.c maintainance is a different issue. I could just add myself to the existing entry, or create a new one specifically for udmabuf. > > Who should be Cc'ed? > > dim add-missing-cc ftw :-) That just uses get_maintainer.pl according to the docs, so that wouldn't change things as that is wired up as sendemail.cccmd already. Except that dim would probably add the list of people to the commit message. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On Wed, Jul 04, 2018 at 07:53:38AM +0200, Gerd Hoffmann wrote: > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: > > On Tue, Jul 03, 2018 at 09:53:58AM +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 > > > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be > > really cool. To give us some assurance that this is generically useful. > > Tomeu? Laurent? > > > Plus an ack from dma-buf folks (nag them on irc, you don't have them on Cc > > here). > > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. Yeah, maintainers entry with you as maintainer plus dri-devel as mailing list plus drm-misc as repo would be good. Just grep for drm-misc.git for tons of examples. > Who should be Cc'ed? dim add-missing-cc ftw :-) Cheers, Daniel > > > Then this is imo good to go. > > > > I assume you'll push it to drm-misc, like all the other dma-buf stuff? > > Can do that, sure, after collecting the acks ... > > thanks, > Gerd > > -- > To unsubscribe from this list: send the line "unsubscribe linux-doc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: > On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: > > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: > > > On Tue, Jul 03, 2018 at 09:53:58AM +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 > > > > > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be > > > really cool. To give us some assurance that this is generically useful. > > > > Tomeu? Laurent? > > Sorry, but I think I will need some help to understand how this could help > in the virtio-wl case [adding Zach Reizner to CC]. > > Any graphics buffers that are allocated with memfd will be shared with the > compositor via wl_shm, without need for dmabufs. Within one machine, yes. Once virtualization is added to the mix things become more complicated ... When using virtio-gpu the guest will allocate graphics buffers from normal (guest) ram, then register these buffers (which are allowed to be scattered) with the host as resource. qemu can use memfd to allocate guest ram. Now, with the help of udmabuf, qemu can create a *host* dma-buf for the *guest* graphics buffer. That dma-buf can be used by qemu internally (mmap it to get a linear mapping of the resource, to avoid copying). It can be passed on to spice-client, to display the guest framebuffer. And I think it could also be quite useful to pass guest wayland windows to the host compositor, without mapping host-allocated buffers into the guest, so we don't have do deal with the "find some address space for the mapping" issue in the first place. There are more things needed to complete this of course, but it's a building block ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: On Tue, Jul 03, 2018 at 09:53:58AM +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 I think some ack for a 2nd use-case, like virtio-wl or whatever would be really cool. To give us some assurance that this is generically useful. Tomeu? Laurent? Sorry, but I think I will need some help to understand how this could help in the virtio-wl case [adding Zach Reizner to CC]. Any graphics buffers that are allocated with memfd will be shared with the compositor via wl_shm, without need for dmabufs. Daniel Stone [added to CC] commented though that this could be useful for browsers that composite pages with a nested Wayland compositor, to avoid having to blit each layer so that the EGL platform notifies the compositor of new contents. Cheers, Tomeu Plus an ack from dma-buf folks (nag them on irc, you don't have them on Cc here). Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. Who should be Cc'ed? Then this is imo good to go. I assume you'll push it to drm-misc, like all the other dma-buf stuff? Can do that, sure, after collecting the acks ... thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: > On Tue, Jul 03, 2018 at 09:53:58AM +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 > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be > really cool. To give us some assurance that this is generically useful. Tomeu? Laurent? > Plus an ack from dma-buf folks (nag them on irc, you don't have them on Cc > here). Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. Who should be Cc'ed? > Then this is imo good to go. > > I assume you'll push it to drm-misc, like all the other dma-buf stuff? Can do that, sure, after collecting the acks ... thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] Add udmabuf misc device
On Tue, Jul 03, 2018 at 09:53:58AM +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 I think some ack for a 2nd use-case, like virtio-wl or whatever would be really cool. To give us some assurance that this is generically useful. Plus an ack from dma-buf folks (nag them on irc, you don't have them on Cc here). Then this is imo good to go. I assume you'll push it to drm-misc, like all the other dma-buf stuff? -Daniel > --- > 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 | 8 + > drivers/dma-buf/Kconfig | 8 + > drivers/dma-buf/Makefile | 1 + > tools/testing/selftests/drivers/dma-buf/Makefile | 5 + > 8 files changed, 439 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 480c8609dc..6636dea476 100644 > --- a/Documentation/ioctl/ioctl-number.txt > +++ b/Documentation/ioctl/ioctl-number.txt > @@ -271,6 +271,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);