All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Keiichi Watanabe <keiichiw@chromium.org>
Cc: "David Stevens" <stevensd@chromium.org>,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Dmitry Morozov" <dmitry.morozov@opensynergy.com>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	geoff@hostfission.com,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org
Subject: guest / host buffer sharing ...
Date: Tue, 5 Nov 2019 11:54:56 +0100	[thread overview]
Message-ID: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> (raw)

  Hi folks,

The issue of sharing buffers between guests and hosts keeps poping
up again and again in different contexts.  Most recently here:

https://www.mail-archive.com/qemu-devel@nongnu.org/msg656685.html

So, I'm grabbing the recipient list of the virtio-vdec thread and some
more people I know might be interested in this, hoping to have everyone
included.

Reason is:  Meanwhile I'm wondering whenever "just use virtio-gpu
resources" is really a good answer for all the different use cases
we have collected over time.  Maybe it is better to have a dedicated
buffer sharing virtio device?  Here is the rough idea:


(1) The virtio device
=====================

Has a single virtio queue, so the guest can send commands to register
and unregister buffers.  Buffers are allocated in guest ram.  Each buffer
has a list of memory ranges for the data.  Each buffer also has some
properties to carry metadata, some fixed (id, size, application), but
also allow free form (name = value, framebuffers would have
width/height/stride/format for example).


(2) The linux guest implementation
==================================

I guess I'd try to make it a drm driver, so we can re-use drm
infrastructure (shmem helpers for example).  Buffers are dumb drm
buffers.  dma-buf import and export is supported (shmem helpers
get us that for free).  Some device-specific ioctls to get/set
properties and to register/unregister the buffers on the host.


(3) The qemu host implementation
================================

qemu (likewise other vmms) can use the udmabuf driver to create
host-side dma-bufs for the buffers.  The dma-bufs can be passed to
anyone interested, inside and outside qemu.  We'll need some protocol
for communication between qemu and external users interested in those
buffers, to receive dma-bufs (via unix file descriptor passing) and
update notifications.  Dispatching updates could be done based on the
application property, which could be "virtio-vdec" or "wayland-proxy"
for example.


commments?

cheers,
  Gerd


WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Keiichi Watanabe <keiichiw@chromium.org>
Cc: geoff@hostfission.com, virtio-dev@lists.oasis-open.org,
	"Alex Lau" <alexlau@chromium.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	qemu-devel@nongnu.org, "Tomasz Figa" <tfiga@chromium.org>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"David Stevens" <stevensd@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: guest / host buffer sharing ...
Date: Tue, 5 Nov 2019 11:54:56 +0100	[thread overview]
Message-ID: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> (raw)

  Hi folks,

The issue of sharing buffers between guests and hosts keeps poping
up again and again in different contexts.  Most recently here:

https://www.mail-archive.com/qemu-devel@nongnu.org/msg656685.html

So, I'm grabbing the recipient list of the virtio-vdec thread and some
more people I know might be interested in this, hoping to have everyone
included.

Reason is:  Meanwhile I'm wondering whenever "just use virtio-gpu
resources" is really a good answer for all the different use cases
we have collected over time.  Maybe it is better to have a dedicated
buffer sharing virtio device?  Here is the rough idea:


(1) The virtio device
=====================

Has a single virtio queue, so the guest can send commands to register
and unregister buffers.  Buffers are allocated in guest ram.  Each buffer
has a list of memory ranges for the data.  Each buffer also has some
properties to carry metadata, some fixed (id, size, application), but
also allow free form (name = value, framebuffers would have
width/height/stride/format for example).


(2) The linux guest implementation
==================================

I guess I'd try to make it a drm driver, so we can re-use drm
infrastructure (shmem helpers for example).  Buffers are dumb drm
buffers.  dma-buf import and export is supported (shmem helpers
get us that for free).  Some device-specific ioctls to get/set
properties and to register/unregister the buffers on the host.


(3) The qemu host implementation
================================

qemu (likewise other vmms) can use the udmabuf driver to create
host-side dma-bufs for the buffers.  The dma-bufs can be passed to
anyone interested, inside and outside qemu.  We'll need some protocol
for communication between qemu and external users interested in those
buffers, to receive dma-bufs (via unix file descriptor passing) and
update notifications.  Dispatching updates could be done based on the
application property, which could be "virtio-vdec" or "wayland-proxy"
for example.


commments?

cheers,
  Gerd



WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Keiichi Watanabe <keiichiw@chromium.org>
Cc: "David Stevens" <stevensd@chromium.org>,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Dmitry Morozov" <dmitry.morozov@opensynergy.com>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	geoff@hostfission.com,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org
Subject: [virtio-dev] guest / host buffer sharing ...
Date: Tue, 5 Nov 2019 11:54:56 +0100	[thread overview]
Message-ID: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> (raw)

  Hi folks,

The issue of sharing buffers between guests and hosts keeps poping
up again and again in different contexts.  Most recently here:

https://www.mail-archive.com/qemu-devel@nongnu.org/msg656685.html

So, I'm grabbing the recipient list of the virtio-vdec thread and some
more people I know might be interested in this, hoping to have everyone
included.

Reason is:  Meanwhile I'm wondering whenever "just use virtio-gpu
resources" is really a good answer for all the different use cases
we have collected over time.  Maybe it is better to have a dedicated
buffer sharing virtio device?  Here is the rough idea:


(1) The virtio device
=====================

Has a single virtio queue, so the guest can send commands to register
and unregister buffers.  Buffers are allocated in guest ram.  Each buffer
has a list of memory ranges for the data.  Each buffer also has some
properties to carry metadata, some fixed (id, size, application), but
also allow free form (name = value, framebuffers would have
width/height/stride/format for example).


(2) The linux guest implementation
==================================

I guess I'd try to make it a drm driver, so we can re-use drm
infrastructure (shmem helpers for example).  Buffers are dumb drm
buffers.  dma-buf import and export is supported (shmem helpers
get us that for free).  Some device-specific ioctls to get/set
properties and to register/unregister the buffers on the host.


(3) The qemu host implementation
================================

qemu (likewise other vmms) can use the udmabuf driver to create
host-side dma-bufs for the buffers.  The dma-bufs can be passed to
anyone interested, inside and outside qemu.  We'll need some protocol
for communication between qemu and external users interested in those
buffers, to receive dma-bufs (via unix file descriptor passing) and
update notifications.  Dispatching updates could be done based on the
application property, which could be "virtio-vdec" or "wayland-proxy"
for example.


commments?

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-11-05 10:55 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 10:54 Gerd Hoffmann [this message]
2019-11-05 10:54 ` [virtio-dev] guest / host buffer sharing 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                   ` [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=20191105105456.7xbhtistnbp272lj@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 \
    /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.