All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: David Stevens <stevensd@chromium.org>
Cc: "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: guest / host buffer sharing ...
Date: Wed, 11 Dec 2019 10:26:25 +0100	[thread overview]
Message-ID: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAD=HUj40Jb2cy8EP=24coO-CPUvq6ib+01bvXHn1G9GD8KuenA@mail.gmail.com>

  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.

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


WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: David Stevens <stevensd@chromium.org>
Cc: "Geoffrey McRae" <geoff@hostfission.com>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Zach Reizner" <zachr@chromium.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	virtio-dev@lists.oasis-open.org,
	qemu-devel <qemu-devel@nongnu.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Keiichi Watanabe" <keiichiw@chromium.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Dmitry Morozov" <dmitry.morozov@opensynergy.com>,
	"Pawel Osciak" <posciak@chromium.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>
Subject: Re: guest / host buffer sharing ...
Date: Wed, 11 Dec 2019 10:26:25 +0100	[thread overview]
Message-ID: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAD=HUj40Jb2cy8EP=24coO-CPUvq6ib+01bvXHn1G9GD8KuenA@mail.gmail.com>

  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.

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



WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: David Stevens <stevensd@chromium.org>
Cc: "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: [virtio-dev] Re: guest / host buffer sharing ...
Date: Wed, 11 Dec 2019 10:26:25 +0100	[thread overview]
Message-ID: <20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAD=HUj40Jb2cy8EP=24coO-CPUvq6ib+01bvXHn1G9GD8KuenA@mail.gmail.com>

  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.

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


  reply	other threads:[~2019-12-11  9:26 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 [this message]
2019-12-11  9:26                   ` [virtio-dev] " Gerd Hoffmann
2019-12-11  9:26                   ` Gerd Hoffmann
2019-12-11 16:05                   ` [virtio-dev] " Enrico Granata
2019-12-11 16:05                     ` 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=20191211092625.jzqx2ukphhggwavo@sirius.home.kraxel.org \
    --to=kraxel@redhat.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=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: link
Be 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.