From: Enrico Granata <egranata@google.com> To: Gerd Hoffmann <kraxel@redhat.com> Cc: "David Stevens" <stevensd@chromium.org>, "Dylan Reid" <dgreid@chromium.org>, "Tomasz Figa" <tfiga@chromium.org>, "Zach Reizner" <zachr@chromium.org>, "Geoffrey McRae" <geoff@hostfission.com>, "Keiichi Watanabe" <keiichiw@chromium.org>, "Dmitry Morozov" <dmitry.morozov@opensynergy.com>, "Alexandre Courbot" <acourbot@chromium.org>, "Alex Lau" <alexlau@chromium.org>, "Stéphane Marchesin" <marcheu@chromium.org>, "Pawel Osciak" <posciak@chromium.org>, "Hans Verkuil" <hverkuil@xs4all.nl>, "Daniel Vetter" <daniel@ffwll.ch>, "Gurchetan Singh" <gurchetansingh@chromium.org>, "Linux Media Mailing List" <linux-media@vger.kernel.org>, virtio-dev@lists.oasis-open.org, qemu-devel <qemu-devel@nongnu.org> Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... Date: Wed, 11 Dec 2019 08:05:40 -0800 [thread overview] Message-ID: <CAPR809tr7cY_ONLgc2Gq2hzuR+FZrtJ5nsLsq-UmV0LxFu0CRA@mail.gmail.com> (raw) In-Reply-To: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> On Wed, Dec 11, 2019 at 1:26 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > None of the proposals directly address the use case of sharing host > > allocated buffers between devices, but I think they can be extended to > > support it. Host buffers can be identified by the following tuple: > > (transport type enum, transport specific device address, shmid, > > offset). I think this is sufficient even for host-allocated buffers > > that aren't visible to the guest (e.g. protected memory, vram), since > > they can still be given address space in some shared memory region, > > even if those addresses are actually inaccessible to the guest. At > > this point, the host buffer identifier can simply be passed in place > > of the guest ram scatterlist with either proposed buffer sharing > > mechanism. > > > I think the main question here is whether or not the complexity of > > generic buffers and a buffer sharing device is worth it compared to > > the more implicit definition of buffers. > > Here are two issues mixed up. First is, whenever we'll go define a > buffer sharing device or not. Second is how we are going to address > buffers. > > I think defining (and addressing) buffers implicitly is a bad idea. > First the addressing is non-trivial, especially with the "transport > specific device address" in the tuple. Second I think it is a bad idea > from the security point of view. When explicitly exporting buffers it > is easy to restrict access to the actual exports. > Strong +1 to the above. There are definitely use cases of interest where it makes sense to be able to attach security attributes to buffers. Having an explicit interface that can handle all of this, instead of duplicating logic in several subsystems, seems a worthy endeavor to me. > Instead of using a dedicated buffer sharing device we can also use > virtio-gpu (or any other driver which supports dma-buf exports) to > manage buffers. virtio-gpu would create an identifier when exporting a > buffer (dma-buf exports inside the guest), attach the identifier to the > dma-buf so other drivers importing the buffer can see and use it. Maybe > add an ioctl to query, so guest userspace can query the identifier too. > Also send the identifier to the host so it can also be used on the host > side to lookup and access the buffer. > > With no central instance (buffer sharing device) being there managing > the buffer identifiers I think using uuids as identifiers would be a > good idea, to avoid clashes. Also good for security because it's pretty > much impossible to guess buffer identifiers then. > > cheers, > Gerd > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org >
WARNING: multiple messages have this Message-ID (diff)
From: Enrico Granata <egranata@google.com> To: Gerd Hoffmann <kraxel@redhat.com> Cc: "David Stevens" <stevensd@chromium.org>, "Dylan Reid" <dgreid@chromium.org>, "Tomasz Figa" <tfiga@chromium.org>, "Zach Reizner" <zachr@chromium.org>, "Geoffrey McRae" <geoff@hostfission.com>, "Keiichi Watanabe" <keiichiw@chromium.org>, "Dmitry Morozov" <dmitry.morozov@opensynergy.com>, "Alexandre Courbot" <acourbot@chromium.org>, "Alex Lau" <alexlau@chromium.org>, "Stéphane Marchesin" <marcheu@chromium.org>, "Pawel Osciak" <posciak@chromium.org>, "Hans Verkuil" <hverkuil@xs4all.nl>, "Daniel Vetter" <daniel@ffwll.ch>, "Gurchetan Singh" <gurchetansingh@chromium.org>, "Linux Media Mailing List" <linux-media@vger.kernel.org>, virtio-dev@lists.oasis-open.org, qemu-devel <qemu-devel@nongnu.org> Subject: Re: [virtio-dev] Re: guest / host buffer sharing ... Date: Wed, 11 Dec 2019 08:05:40 -0800 [thread overview] Message-ID: <CAPR809tr7cY_ONLgc2Gq2hzuR+FZrtJ5nsLsq-UmV0LxFu0CRA@mail.gmail.com> (raw) In-Reply-To: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> On Wed, Dec 11, 2019 at 1:26 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > None of the proposals directly address the use case of sharing host > > allocated buffers between devices, but I think they can be extended to > > support it. Host buffers can be identified by the following tuple: > > (transport type enum, transport specific device address, shmid, > > offset). I think this is sufficient even for host-allocated buffers > > that aren't visible to the guest (e.g. protected memory, vram), since > > they can still be given address space in some shared memory region, > > even if those addresses are actually inaccessible to the guest. At > > this point, the host buffer identifier can simply be passed in place > > of the guest ram scatterlist with either proposed buffer sharing > > mechanism. > > > I think the main question here is whether or not the complexity of > > generic buffers and a buffer sharing device is worth it compared to > > the more implicit definition of buffers. > > Here are two issues mixed up. First is, whenever we'll go define a > buffer sharing device or not. Second is how we are going to address > buffers. > > I think defining (and addressing) buffers implicitly is a bad idea. > First the addressing is non-trivial, especially with the "transport > specific device address" in the tuple. Second I think it is a bad idea > from the security point of view. When explicitly exporting buffers it > is easy to restrict access to the actual exports. > Strong +1 to the above. There are definitely use cases of interest where it makes sense to be able to attach security attributes to buffers. Having an explicit interface that can handle all of this, instead of duplicating logic in several subsystems, seems a worthy endeavor to me. > Instead of using a dedicated buffer sharing device we can also use > virtio-gpu (or any other driver which supports dma-buf exports) to > manage buffers. virtio-gpu would create an identifier when exporting a > buffer (dma-buf exports inside the guest), attach the identifier to the > dma-buf so other drivers importing the buffer can see and use it. Maybe > add an ioctl to query, so guest userspace can query the identifier too. > Also send the identifier to the host so it can also be used on the host > side to lookup and access the buffer. > > With no central instance (buffer sharing device) being there managing > the buffer identifiers I think using uuids as identifiers would be a > good idea, to avoid clashes. Also good for security because it's pretty > much impossible to guess buffer identifiers then. > > cheers, > Gerd > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2019-12-11 16:05 UTC|newest] Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-05 10:54 guest / host buffer sharing Gerd Hoffmann 2019-11-05 10:54 ` [virtio-dev] " Gerd Hoffmann 2019-11-05 10:54 ` Gerd Hoffmann 2019-11-05 11:35 ` Geoffrey McRae 2019-11-06 6:24 ` Gerd Hoffmann 2019-11-06 6:24 ` [virtio-dev] " Gerd Hoffmann 2019-11-06 6:24 ` Gerd Hoffmann 2019-11-06 8:36 ` David Stevens 2019-11-06 8:36 ` [virtio-dev] " David Stevens 2019-11-06 8:36 ` David Stevens 2019-11-06 12:41 ` Gerd Hoffmann 2019-11-06 12:41 ` [virtio-dev] " Gerd Hoffmann 2019-11-06 12:41 ` Gerd Hoffmann 2019-11-06 22:28 ` Geoffrey McRae 2019-11-07 6:48 ` Gerd Hoffmann 2019-11-07 6:48 ` [virtio-dev] " Gerd Hoffmann 2019-11-07 6:48 ` Gerd Hoffmann 2019-11-20 12:13 ` Tomasz Figa 2019-11-20 12:13 ` [virtio-dev] " Tomasz Figa 2019-11-20 12:13 ` Tomasz Figa 2019-11-20 21:41 ` Geoffrey McRae 2019-11-21 5:51 ` Tomasz Figa 2019-11-21 5:51 ` [virtio-dev] " Tomasz Figa 2019-11-21 5:51 ` Tomasz Figa 2019-12-04 22:22 ` Dylan Reid 2019-12-04 22:22 ` Dylan Reid 2019-12-11 5:08 ` David Stevens 2019-12-11 5:08 ` [virtio-dev] " David Stevens 2019-12-11 5:08 ` David Stevens 2019-12-11 9:26 ` Gerd Hoffmann 2019-12-11 9:26 ` [virtio-dev] " Gerd Hoffmann 2019-12-11 9:26 ` Gerd Hoffmann 2019-12-11 16:05 ` Enrico Granata [this message] 2019-12-11 16:05 ` [virtio-dev] " Enrico Granata 2019-12-12 6:40 ` David Stevens 2019-12-12 6:40 ` David Stevens 2019-12-12 6:40 ` David Stevens 2019-12-12 9:41 ` Gerd Hoffmann 2019-12-12 9:41 ` Gerd Hoffmann 2019-12-12 9:41 ` Gerd Hoffmann 2019-12-12 12:26 ` David Stevens 2019-12-12 12:26 ` David Stevens 2019-12-12 12:26 ` David Stevens 2019-12-12 13:30 ` Gerd Hoffmann 2019-12-12 13:30 ` Gerd Hoffmann 2019-12-12 13:30 ` Gerd Hoffmann 2019-12-13 3:21 ` David Stevens 2019-12-13 3:21 ` David Stevens 2019-12-13 3:21 ` David Stevens 2019-12-16 13:47 ` Gerd Hoffmann 2019-12-16 13:47 ` Gerd Hoffmann 2019-12-16 13:47 ` Gerd Hoffmann 2019-12-17 12:59 ` David Stevens 2019-12-17 12:59 ` David Stevens 2019-12-17 12:59 ` David Stevens 2019-11-06 8:43 ` Stefan Hajnoczi 2019-11-06 8:43 ` Stefan Hajnoczi 2019-11-06 9:51 ` Gerd Hoffmann 2019-11-06 9:51 ` [virtio-dev] " Gerd Hoffmann 2019-11-06 9:51 ` Gerd Hoffmann 2019-11-06 10:10 ` [virtio-dev] " Dr. David Alan Gilbert 2019-11-06 10:10 ` Dr. David Alan Gilbert 2019-11-06 10:10 ` Dr. David Alan Gilbert 2019-11-07 11:11 ` Gerd Hoffmann 2019-11-07 11:11 ` Gerd Hoffmann 2019-11-07 11:11 ` Gerd Hoffmann 2019-11-07 11:16 ` Dr. David Alan Gilbert 2019-11-07 11:16 ` Dr. David Alan Gilbert 2019-11-07 11:16 ` Dr. David Alan Gilbert 2019-11-08 6:45 ` Gerd Hoffmann 2019-11-08 6:45 ` Gerd Hoffmann 2019-11-08 6:45 ` Gerd Hoffmann 2019-11-06 11:46 ` Stefan Hajnoczi 2019-11-06 11:46 ` Stefan Hajnoczi 2019-11-06 12:50 ` Gerd Hoffmann 2019-11-06 12:50 ` [virtio-dev] " Gerd Hoffmann 2019-11-06 12:50 ` Gerd Hoffmann 2019-11-07 12:10 ` Stefan Hajnoczi 2019-11-07 12:10 ` Stefan Hajnoczi 2019-11-07 15:10 ` Frank Yang 2019-11-07 15:10 ` [virtio-dev] " Frank Yang 2019-11-20 11:58 ` Tomasz Figa 2019-11-20 11:58 ` [virtio-dev] " Tomasz Figa 2019-11-20 11:58 ` Tomasz Figa 2019-11-08 7:22 ` Gerd Hoffmann 2019-11-08 7:22 ` [virtio-dev] " Gerd Hoffmann 2019-11-08 7:22 ` Gerd Hoffmann 2019-11-08 7:35 ` Stefan Hajnoczi 2019-11-08 7:35 ` Stefan Hajnoczi 2019-11-09 1:41 ` Stéphane Marchesin 2019-11-09 1:41 ` Stéphane Marchesin 2019-11-09 10:12 ` Stefan Hajnoczi 2019-11-09 10:12 ` Stefan Hajnoczi 2019-11-09 11:16 ` Tomasz Figa 2019-11-09 11:16 ` [virtio-dev] " Tomasz Figa 2019-11-09 11:16 ` Tomasz Figa 2019-11-09 12:08 ` Stefan Hajnoczi 2019-11-09 12:08 ` Stefan Hajnoczi 2019-11-09 15:12 ` Tomasz Figa 2019-11-09 15:12 ` [virtio-dev] " Tomasz Figa 2019-11-09 15:12 ` Tomasz Figa 2019-11-18 10:20 ` Stefan Hajnoczi 2019-11-18 10:20 ` Stefan Hajnoczi 2019-11-20 10:11 ` Tomasz Figa 2019-11-20 10:11 ` [virtio-dev] " Tomasz Figa 2019-11-20 10:11 ` Tomasz Figa 2019-11-20 12:11 ` Tomasz Figa 2019-11-20 12:11 ` [virtio-dev] " Tomasz Figa 2019-11-20 12:11 ` Tomasz Figa 2019-11-11 3:04 ` David Stevens 2019-11-11 3:04 ` [virtio-dev] " David Stevens 2019-11-11 3:04 ` David Stevens 2019-11-11 15:36 ` [virtio-dev] " Liam Girdwood 2019-11-11 15:36 ` Liam Girdwood 2019-11-11 15:36 ` Liam Girdwood 2019-11-12 0:54 ` Gurchetan Singh 2019-11-12 0:54 ` Gurchetan Singh 2019-11-12 0:54 ` Gurchetan Singh 2019-11-12 13:56 ` Liam Girdwood 2019-11-12 13:56 ` Liam Girdwood 2019-11-12 13:56 ` Liam Girdwood 2019-11-12 22:55 ` Gurchetan Singh 2019-11-12 22:55 ` Gurchetan Singh 2019-11-12 22:55 ` Gurchetan Singh 2019-11-19 15:31 ` Liam Girdwood 2019-11-19 15:31 ` Liam Girdwood 2019-11-19 15:31 ` Liam Girdwood 2019-11-20 0:42 ` Gurchetan Singh 2019-11-20 0:42 ` Gurchetan Singh 2019-11-20 0:42 ` Gurchetan Singh 2019-11-20 9:53 ` Gerd Hoffmann 2019-11-20 9:53 ` Gerd Hoffmann 2019-11-20 9:53 ` Gerd Hoffmann 2019-11-25 16:46 ` Liam Girdwood 2019-11-25 16:46 ` Liam Girdwood 2019-11-25 16:46 ` Liam Girdwood 2019-11-27 7:58 ` Gerd Hoffmann 2019-11-27 7:58 ` Gerd Hoffmann 2019-11-27 7:58 ` Gerd Hoffmann
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=CAPR809tr7cY_ONLgc2Gq2hzuR+FZrtJ5nsLsq-UmV0LxFu0CRA@mail.gmail.com \ --to=egranata@google.com \ --cc=acourbot@chromium.org \ --cc=alexlau@chromium.org \ --cc=daniel@ffwll.ch \ --cc=dgreid@chromium.org \ --cc=dmitry.morozov@opensynergy.com \ --cc=geoff@hostfission.com \ --cc=gurchetansingh@chromium.org \ --cc=hverkuil@xs4all.nl \ --cc=keiichiw@chromium.org \ --cc=kraxel@redhat.com \ --cc=linux-media@vger.kernel.org \ --cc=marcheu@chromium.org \ --cc=posciak@chromium.org \ --cc=qemu-devel@nongnu.org \ --cc=stevensd@chromium.org \ --cc=tfiga@chromium.org \ --cc=virtio-dev@lists.oasis-open.org \ --cc=zachr@chromium.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.