From: "Roger Pau Monné" <roger.pau@citrix.com> To: Oleksandr Andrushchenko <andr2000@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com>, "Oleksandr_Andrushchenko@epam.com" <Oleksandr_Andrushchenko@epam.com>, <jgross@suse.com>, Artem Mygaiev <Artem_Mygaiev@epam.com>, <konrad.wilk@oracle.com>, <airlied@linux.ie>, <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>, Matt Roper <matthew.d.roper@intel.com> Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Date: Wed, 18 Apr 2018 08:35:08 +0100 [thread overview] Message-ID: <20180418073508.ptvntwedczpvl7bx@MacBook-Pro-de-Roger.local> (raw) In-Reply-To: <41487acb-a67a-8933-d0c3-702c19b0938e@gmail.com> On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > 3.2 Backend exports dma-buf to xen-front > > In this case Dom0 pages are shared with DomU. As before, DomU can only write > to these pages, not any other page from Dom0, so it can be still considered > safe. > But, the following must be considered (highlighted in xen-front's Kernel > documentation): > - If guest domain dies then pages/grants received from the backend cannot > be claimed back - think of it as memory lost to Dom0 (won't be used for > any > other guest) > - Misbehaving guest may send too many requests to the backend exhausting > its grant references and memory (consider this from security POV). As the > backend runs in the trusted domain we also assume that it is trusted as > well, > e.g. must take measures to prevent DDoS attacks. I cannot parse the above sentence: "As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks." What's the relation between being trusted and protecting from DoS attacks? In any case, all? PV protocols are implemented with the frontend sharing pages to the backend, and I think there's a reason why this model is used, and it should continue to be used. Having to add logic in the backend to prevent such attacks means that: - We need more code in the backend, which increases complexity and chances of bugs. - Such code/logic could be wrong, thus allowing DoS. > 4. xen-front/backend/xen-zcopy synchronization > > 4.1. As I already said in 2) all the inter VM communication happens between > xen-front and the backend, xen-zcopy is NOT involved in that. > When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a > XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). > This call is synchronous, so xen-front expects that backend does free the > buffer pages on return. > > 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: > - closes all dumb handles/fd's of the buffer according to [3] > - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make > sure > the buffer is freed (think of it as it waits for dma-buf->release > callback) So this zcopy thing keeps some kind of track of the memory usage? Why can't the user-space backend keep track of the buffer usage? > - replies to xen-front that the buffer can be destroyed. > This way deletion of the buffer happens synchronously on both Dom0 and DomU > sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out > error > (BTW, wait time is a parameter of this IOCTL), Xen will defer grant > reference > removal and will retry later until those are free. > > Hope this helps understand how buffers are synchronously deleted in case > of xen-zcopy with a single protocol command. > > I think the above logic can also be re-used by the hyper-dmabuf driver with > some additional work: > > 1. xen-zcopy can be split into 2 parts and extend: > 1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and > vise versa, I don't know much about the dma-buf implementation in Linux, but gntdev is a user-space device, and AFAICT user-space applications don't have any notion of dma buffers. How are such buffers useful for user-space? Why can't this just be called memory? Also, (with my FreeBSD maintainer hat) how is this going to translate to other OSes? So far the operations performed by the gntdev device are mostly OS-agnostic because this just map/unmap memory, and in fact they are implemented by Linux and FreeBSD. > implement "wait" ioctl (wait for dma-buf->release): currently these are > DRM_XEN_ZCOPY_DUMB_FROM_REFS, DRM_XEN_ZCOPY_DUMB_TO_REFS and > DRM_XEN_ZCOPY_DUMB_WAIT_FREE > 1.2. Xen balloon driver [6] to allow allocating contiguous buffers (not > needed > by current hyper-dmabuf, but is a must for xen-zcopy use-cases) I think this needs clarifying. In which memory space do you need those regions to be contiguous? Do they need to be contiguous in host physical memory, or guest physical memory? If it's in guest memory space, isn't there any generic interface that you can use? If it's in host physical memory space, why do you need this buffer to be contiguous in host physical memory space? The IOMMU should hide all this. Thanks, Roger.
WARNING: multiple messages have this Message-ID (diff)
From: "Roger Pau Monné" <roger.pau@citrix.com> To: Oleksandr Andrushchenko <andr2000@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com>, "Oleksandr_Andrushchenko@epam.com" <Oleksandr_Andrushchenko@epam.com>, jgross@suse.com, Artem Mygaiev <Artem_Mygaiev@epam.com>, konrad.wilk@oracle.com, airlied@linux.ie, 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, Matt Roper <matthew.d.roper@intel.com> Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Date: Wed, 18 Apr 2018 08:35:08 +0100 [thread overview] Message-ID: <20180418073508.ptvntwedczpvl7bx@MacBook-Pro-de-Roger.local> (raw) In-Reply-To: <41487acb-a67a-8933-d0c3-702c19b0938e@gmail.com> On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > 3.2 Backend exports dma-buf to xen-front > > In this case Dom0 pages are shared with DomU. As before, DomU can only write > to these pages, not any other page from Dom0, so it can be still considered > safe. > But, the following must be considered (highlighted in xen-front's Kernel > documentation): > - If guest domain dies then pages/grants received from the backend cannot > be claimed back - think of it as memory lost to Dom0 (won't be used for > any > other guest) > - Misbehaving guest may send too many requests to the backend exhausting > its grant references and memory (consider this from security POV). As the > backend runs in the trusted domain we also assume that it is trusted as > well, > e.g. must take measures to prevent DDoS attacks. I cannot parse the above sentence: "As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks." What's the relation between being trusted and protecting from DoS attacks? In any case, all? PV protocols are implemented with the frontend sharing pages to the backend, and I think there's a reason why this model is used, and it should continue to be used. Having to add logic in the backend to prevent such attacks means that: - We need more code in the backend, which increases complexity and chances of bugs. - Such code/logic could be wrong, thus allowing DoS. > 4. xen-front/backend/xen-zcopy synchronization > > 4.1. As I already said in 2) all the inter VM communication happens between > xen-front and the backend, xen-zcopy is NOT involved in that. > When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a > XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). > This call is synchronous, so xen-front expects that backend does free the > buffer pages on return. > > 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: > - closes all dumb handles/fd's of the buffer according to [3] > - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make > sure > the buffer is freed (think of it as it waits for dma-buf->release > callback) So this zcopy thing keeps some kind of track of the memory usage? Why can't the user-space backend keep track of the buffer usage? > - replies to xen-front that the buffer can be destroyed. > This way deletion of the buffer happens synchronously on both Dom0 and DomU > sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out > error > (BTW, wait time is a parameter of this IOCTL), Xen will defer grant > reference > removal and will retry later until those are free. > > Hope this helps understand how buffers are synchronously deleted in case > of xen-zcopy with a single protocol command. > > I think the above logic can also be re-used by the hyper-dmabuf driver with > some additional work: > > 1. xen-zcopy can be split into 2 parts and extend: > 1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and > vise versa, I don't know much about the dma-buf implementation in Linux, but gntdev is a user-space device, and AFAICT user-space applications don't have any notion of dma buffers. How are such buffers useful for user-space? Why can't this just be called memory? Also, (with my FreeBSD maintainer hat) how is this going to translate to other OSes? So far the operations performed by the gntdev device are mostly OS-agnostic because this just map/unmap memory, and in fact they are implemented by Linux and FreeBSD. > implement "wait" ioctl (wait for dma-buf->release): currently these are > DRM_XEN_ZCOPY_DUMB_FROM_REFS, DRM_XEN_ZCOPY_DUMB_TO_REFS and > DRM_XEN_ZCOPY_DUMB_WAIT_FREE > 1.2. Xen balloon driver [6] to allow allocating contiguous buffers (not > needed > by current hyper-dmabuf, but is a must for xen-zcopy use-cases) I think this needs clarifying. In which memory space do you need those regions to be contiguous? Do they need to be contiguous in host physical memory, or guest physical memory? If it's in guest memory space, isn't there any generic interface that you can use? If it's in host physical memory space, why do you need this buffer to be contiguous in host physical memory space? The IOMMU should hide all this. Thanks, Roger.
next prev parent reply other threads:[~2018-04-18 7:35 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 ` Roger Pau Monné [this message] 2018-04-18 7:35 ` [Xen-devel] " 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 ` [Xen-devel] " Daniel Vetter 2018-04-24 11:54 ` 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=20180418073508.ptvntwedczpvl7bx@MacBook-Pro-de-Roger.local \ --to=roger.pau@citrix.com \ --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=matthew.d.roper@intel.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.