From: Daniel Vetter <daniel@ffwll.ch> To: Oleksandr Andrushchenko <andr2000@gmail.com> Cc: "Wei Liu" <wei.liu2@citrix.com>, jgross@suse.com, "Artem Mygaiev" <Artem_Mygaiev@epam.com>, "Dongwon Kim" <dongwon.kim@intel.com>, konrad.wilk@oracle.com, airlied@linux.ie, "Oleksandr_Andrushchenko@epam.com" <Oleksandr_Andrushchenko@epam.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "Potrola, MateuszX" <mateuszx.potrola@intel.com>, daniel.vetter@intel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, "Roger Pau Monné" <roger.pau@citrix.com> Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Date: Tue, 24 Apr 2018 13:54:37 +0200 [thread overview] Message-ID: <20180424115437.GT31310@phenom.ffwll.local> (raw) In-Reply-To: <61105351-8896-072b-abf0-757c7f6c0edf@gmail.com> On Mon, Apr 23, 2018 at 03:10:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/23/2018 02:52 PM, Wei Liu wrote: > > On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: > > > > > the gntdev. > > > > > > > > > > I think this is generic enough that it could be implemented by a > > > > > device not tied to Xen. AFAICT the hyper_dma guys also wanted > > > > > something similar to this. > > > > You can't just wrap random userspace memory into a dma-buf. We've just had > > > > this discussion with kvm/qemu folks, who proposed just that, and after a > > > > bit of discussion they'll now try to have a driver which just wraps a > > > > memfd into a dma-buf. > > > So, we have to decide either we introduce a new driver > > > (say, under drivers/xen/xen-dma-buf) or extend the existing > > > gntdev/balloon to support dma-buf use-cases. > > > > > > Can anybody from Xen community express their preference here? > > > > > Oleksandr talked to me on IRC about this, he said a few IOCTLs need to > > be added to either existing drivers or a new driver. > > > > I went through this thread twice and skimmed through the relevant > > documents, but I couldn't see any obvious pros and cons for either > > approach. So I don't really have an opinion on this. > > > > But, assuming if implemented in existing drivers, those IOCTLs need to > > be added to different drivers, which means userspace program needs to > > write more code and get more handles, it would be slightly better to > > implement a new driver from that perspective. > If gntdev/balloon extension is still considered: > > All the IOCTLs will be in gntdev driver (in current xen-zcopy terminology): > - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS > - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS > - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE s/DUMB/DMA_BUF/ please. This is generic dma-buf, it has nothing to do with the dumb scanout buffer support in the drm/gfx subsystem. This here can be used for any zcopy sharing among guests (as long as your endpoints understands dma-buf, which most relevant drivers do). -Daniel > > Balloon driver extension, which is needed for contiguous/DMA > buffers, will be to provide new *kernel API*, no UAPI is needed. > > > Wei. > Thank you, > Oleksandr > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Oleksandr Andrushchenko <andr2000@gmail.com> Cc: jgross@suse.com, "Artem Mygaiev" <Artem_Mygaiev@epam.com>, "Wei Liu" <wei.liu2@citrix.com>, "Dongwon Kim" <dongwon.kim@intel.com>, konrad.wilk@oracle.com, airlied@linux.ie, "Oleksandr_Andrushchenko@epam.com" <Oleksandr_Andrushchenko@epam.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "Potrola, MateuszX" <mateuszx.potrola@intel.com>, xen-devel@lists.xenproject.org, daniel.vetter@intel.com, boris.ostrovsky@oracle.com, "Roger Pau Monné" <roger.pau@citrix.com> Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Date: Tue, 24 Apr 2018 13:54:37 +0200 [thread overview] Message-ID: <20180424115437.GT31310@phenom.ffwll.local> (raw) In-Reply-To: <61105351-8896-072b-abf0-757c7f6c0edf@gmail.com> On Mon, Apr 23, 2018 at 03:10:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/23/2018 02:52 PM, Wei Liu wrote: > > On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: > > > > > the gntdev. > > > > > > > > > > I think this is generic enough that it could be implemented by a > > > > > device not tied to Xen. AFAICT the hyper_dma guys also wanted > > > > > something similar to this. > > > > You can't just wrap random userspace memory into a dma-buf. We've just had > > > > this discussion with kvm/qemu folks, who proposed just that, and after a > > > > bit of discussion they'll now try to have a driver which just wraps a > > > > memfd into a dma-buf. > > > So, we have to decide either we introduce a new driver > > > (say, under drivers/xen/xen-dma-buf) or extend the existing > > > gntdev/balloon to support dma-buf use-cases. > > > > > > Can anybody from Xen community express their preference here? > > > > > Oleksandr talked to me on IRC about this, he said a few IOCTLs need to > > be added to either existing drivers or a new driver. > > > > I went through this thread twice and skimmed through the relevant > > documents, but I couldn't see any obvious pros and cons for either > > approach. So I don't really have an opinion on this. > > > > But, assuming if implemented in existing drivers, those IOCTLs need to > > be added to different drivers, which means userspace program needs to > > write more code and get more handles, it would be slightly better to > > implement a new driver from that perspective. > If gntdev/balloon extension is still considered: > > All the IOCTLs will be in gntdev driver (in current xen-zcopy terminology): > - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS > - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS > - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE s/DUMB/DMA_BUF/ please. This is generic dma-buf, it has nothing to do with the dumb scanout buffer support in the drm/gfx subsystem. This here can be used for any zcopy sharing among guests (as long as your endpoints understands dma-buf, which most relevant drivers do). -Daniel > > Balloon driver extension, which is needed for contiguous/DMA > buffers, will be to provide new *kernel API*, no UAPI is needed. > > > Wei. > Thank you, > Oleksandr > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
next prev parent reply other threads:[~2018-04-24 11:54 UTC|newest] Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-29 13:19 [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Oleksandr Andrushchenko 2018-03-29 13:19 ` Oleksandr Andrushchenko 2018-03-29 13:19 ` [PATCH 1/1] " Oleksandr Andrushchenko 2018-03-29 13:19 ` Oleksandr Andrushchenko 2018-03-29 13:19 ` Oleksandr Andrushchenko 2018-04-03 9:47 ` Daniel Vetter 2018-04-03 9:47 ` Daniel Vetter 2018-04-03 9:47 ` Daniel Vetter 2018-04-06 11:25 ` Oleksandr Andrushchenko 2018-04-06 11:25 ` Oleksandr Andrushchenko 2018-04-06 11:25 ` Oleksandr Andrushchenko 2018-04-09 8:27 ` Daniel Vetter 2018-04-09 8:27 ` Daniel Vetter 2018-04-09 8:27 ` Daniel Vetter 2018-04-16 14:33 ` [PATCH 0/1] " Oleksandr Andrushchenko 2018-04-16 19:29 ` Dongwon Kim 2018-04-16 19:29 ` Dongwon Kim 2018-04-16 19:29 ` Dongwon Kim 2018-04-17 7:59 ` Daniel Vetter 2018-04-17 7:59 ` Daniel Vetter 2018-04-17 7:59 ` Daniel Vetter 2018-04-17 8:19 ` Oleksandr Andrushchenko 2018-04-17 8:19 ` Oleksandr Andrushchenko 2018-04-17 8:19 ` Oleksandr Andrushchenko 2018-04-17 20:57 ` Dongwon Kim 2018-04-17 20:57 ` Dongwon Kim 2018-04-18 6:38 ` Oleksandr Andrushchenko 2018-04-18 7:35 ` Roger Pau Monné 2018-04-18 7:35 ` [Xen-devel] " Roger Pau Monné 2018-04-18 7:35 ` Roger Pau Monné 2018-04-18 8:01 ` Oleksandr Andrushchenko 2018-04-18 8:01 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-18 8:01 ` Oleksandr Andrushchenko 2018-04-18 10:10 ` Roger Pau Monné 2018-04-18 10:10 ` [Xen-devel] " Roger Pau Monné 2018-04-18 10:10 ` Roger Pau Monné 2018-04-18 10:18 ` Paul Durrant 2018-04-18 10:21 ` Oleksandr Andrushchenko 2018-04-18 10:21 ` Oleksandr Andrushchenko 2018-04-18 10:23 ` Paul Durrant 2018-04-18 10:31 ` Oleksandr Andrushchenko 2018-04-18 10:31 ` Oleksandr Andrushchenko 2018-04-18 10:23 ` Paul Durrant 2018-04-18 10:21 ` Oleksandr Andrushchenko 2018-04-18 10:39 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-18 10:39 ` Oleksandr Andrushchenko 2018-04-18 10:55 ` Roger Pau Monné 2018-04-18 10:55 ` [Xen-devel] " Roger Pau Monné 2018-04-18 12:42 ` Oleksandr Andrushchenko 2018-04-18 16:01 ` Dongwon Kim 2018-04-18 16:01 ` Dongwon Kim 2018-04-19 8:19 ` Oleksandr Andrushchenko 2018-04-19 8:19 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-19 8:19 ` Oleksandr Andrushchenko 2018-04-18 16:01 ` Dongwon Kim 2018-04-18 12:42 ` Oleksandr Andrushchenko 2018-04-20 7:22 ` Daniel Vetter 2018-04-20 7:22 ` [Xen-devel] " Daniel Vetter 2018-04-20 7:22 ` Daniel Vetter 2018-04-18 10:39 ` Oleksandr Andrushchenko 2018-04-18 10:18 ` Paul Durrant 2018-04-20 7:19 ` [Xen-devel] " Daniel Vetter 2018-04-20 11:25 ` Oleksandr Andrushchenko 2018-04-20 11:25 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-20 11:25 ` Oleksandr Andrushchenko 2018-04-23 11:52 ` Wei Liu 2018-04-23 12:10 ` Oleksandr Andrushchenko 2018-04-23 12:10 ` Oleksandr Andrushchenko 2018-04-23 22:41 ` Boris Ostrovsky 2018-04-23 22:41 ` [Xen-devel] " Boris Ostrovsky 2018-04-24 5:43 ` Oleksandr Andrushchenko 2018-04-24 5:43 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-24 5:43 ` Oleksandr Andrushchenko 2018-04-24 7:51 ` Juergen Gross 2018-04-24 8:07 ` Oleksandr Andrushchenko 2018-04-24 8:07 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-24 8:07 ` Oleksandr Andrushchenko 2018-04-24 8:40 ` Juergen Gross 2018-04-24 9:03 ` Oleksandr Andrushchenko 2018-04-24 9:03 ` Oleksandr Andrushchenko 2018-04-24 9:08 ` Juergen Gross 2018-04-24 9:13 ` Oleksandr Andrushchenko 2018-04-24 9:13 ` Oleksandr Andrushchenko 2018-04-24 10:01 ` [Xen-devel] " Wei Liu 2018-04-24 10:14 ` Oleksandr Andrushchenko 2018-04-24 10:14 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-24 10:24 ` Juergen Gross 2018-04-24 10:24 ` [Xen-devel] " Juergen Gross 2018-04-24 10:01 ` Wei Liu 2018-04-24 9:08 ` Juergen Gross 2018-04-24 9:03 ` Oleksandr Andrushchenko 2018-04-24 8:40 ` Juergen Gross 2018-04-24 7:51 ` Juergen Gross 2018-04-24 11:54 ` Daniel Vetter 2018-04-24 11:54 ` Daniel Vetter [this message] 2018-04-24 11:54 ` [Xen-devel] " Daniel Vetter 2018-04-24 11:59 ` Oleksandr Andrushchenko 2018-04-24 20:35 ` Dongwon Kim 2018-04-24 20:35 ` [Xen-devel] " Dongwon Kim 2018-04-24 20:35 ` Dongwon Kim 2018-04-25 6:07 ` Oleksandr Andrushchenko 2018-04-25 6:34 ` Daniel Vetter 2018-04-25 6:34 ` [Xen-devel] " Daniel Vetter 2018-04-25 6:34 ` Daniel Vetter 2018-04-25 17:16 ` Dongwon Kim 2018-04-25 17:16 ` Dongwon Kim 2018-04-27 6:54 ` Oleksandr Andrushchenko 2018-04-27 6:54 ` [Xen-devel] " Oleksandr Andrushchenko 2018-04-27 6:54 ` Oleksandr Andrushchenko 2018-04-25 17:16 ` Dongwon Kim 2018-04-25 6:07 ` Oleksandr Andrushchenko 2018-04-25 6:12 ` [Xen-devel] " Juergen Gross 2018-04-30 18:43 ` Dongwon Kim 2018-04-30 18:43 ` Dongwon Kim 2018-04-25 6:12 ` Juergen Gross 2018-04-24 11:59 ` Oleksandr Andrushchenko 2018-04-23 12:10 ` Oleksandr Andrushchenko 2018-04-23 11:52 ` Wei Liu 2018-04-20 7:19 ` Daniel Vetter 2018-04-18 17:01 ` Dongwon Kim 2018-04-18 17:01 ` Dongwon Kim 2018-04-18 17:01 ` Dongwon Kim 2018-04-19 8:14 ` Oleksandr Andrushchenko 2018-04-19 8:14 ` Oleksandr Andrushchenko 2018-04-19 8:14 ` Oleksandr Andrushchenko 2018-04-19 17:55 ` Dongwon Kim 2018-04-19 17:55 ` Dongwon Kim 2018-04-19 17:55 ` Dongwon Kim 2018-04-18 6:38 ` Oleksandr Andrushchenko 2018-04-16 14:33 ` Oleksandr Andrushchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180424115437.GT31310@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=Artem_Mygaiev@epam.com \ --cc=Oleksandr_Andrushchenko@epam.com \ --cc=airlied@linux.ie \ --cc=andr2000@gmail.com \ --cc=boris.ostrovsky@oracle.com \ --cc=daniel.vetter@intel.com \ --cc=dongwon.kim@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jgross@suse.com \ --cc=konrad.wilk@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mateuszx.potrola@intel.com \ --cc=roger.pau@citrix.com \ --cc=wei.liu2@citrix.com \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.