From: David Stevens <stevensd@chromium.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Keiichi Watanabe" <keiichiw@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: Re: guest / host buffer sharing ...
Date: Wed, 6 Nov 2019 17:36:22 +0900 [thread overview]
Message-ID: <CAD=HUj7EsxrkSubmY6HE4aYJOykVKtmGXjMjeGqnoJw1KZUc5Q@mail.gmail.com> (raw)
In-Reply-To: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org>
> (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
Allocating from guest ram would work most of the time, but I think
it's insufficient for many use cases. It doesn't really support things
such as contiguous allocations, allocations from carveouts or <4GB,
protected buffers, etc.
> properties to carry metadata, some fixed (id, size, application), but
What exactly do you mean by application?
> also allow free form (name = value, framebuffers would have
> width/height/stride/format for example).
Is this approach expected to handle allocating buffers with
hardware-specific constraints such as stride/height alignment or
tiling? Or would there need to be some alternative channel for
determining those values and then calculating the appropriate buffer
size?
-David
On Tue, Nov 5, 2019 at 7:55 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> 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
>
next prev parent reply other threads:[~2019-11-06 8:36 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 10:54 guest / host buffer sharing Gerd Hoffmann
2019-11-05 11:35 ` Geoffrey McRae
2019-11-06 6:24 ` Gerd Hoffmann
2019-11-06 8:36 ` David Stevens [this message]
2019-11-06 12:41 ` Gerd Hoffmann
2019-11-06 22:28 ` Geoffrey McRae
2019-11-07 6:48 ` Gerd Hoffmann
2019-11-20 12:13 ` Tomasz Figa
2019-11-20 21:41 ` Geoffrey McRae
2019-11-21 5:51 ` Tomasz Figa
2019-12-04 22:22 ` Dylan Reid
2019-12-11 5:08 ` David Stevens
2019-12-11 9:26 ` Gerd Hoffmann
2019-12-11 16:05 ` [virtio-dev] " Enrico Granata
2019-12-12 6:40 ` David Stevens
2019-12-12 9:41 ` Gerd Hoffmann
2019-12-12 12:26 ` David Stevens
2019-12-12 13:30 ` Gerd Hoffmann
2019-12-13 3:21 ` David Stevens
2019-12-16 13:47 ` Gerd Hoffmann
2019-12-17 12:59 ` David Stevens
2019-11-06 8:43 ` Stefan Hajnoczi
2019-11-06 9:51 ` Gerd Hoffmann
2019-11-06 10:10 ` [virtio-dev] " Dr. David Alan Gilbert
2019-11-07 11:11 ` Gerd Hoffmann
2019-11-07 11:16 ` Dr. David Alan Gilbert
2019-11-08 6:45 ` Gerd Hoffmann
2019-11-06 11:46 ` Stefan Hajnoczi
2019-11-06 12:50 ` Gerd Hoffmann
2019-11-07 12:10 ` Stefan Hajnoczi
2019-11-08 7:22 ` Gerd Hoffmann
2019-11-08 7:35 ` Stefan Hajnoczi
2019-11-09 1:41 ` Stéphane Marchesin
2019-11-09 10:12 ` Stefan Hajnoczi
2019-11-09 11:16 ` Tomasz Figa
2019-11-09 12:08 ` Stefan Hajnoczi
2019-11-09 15:12 ` Tomasz Figa
2019-11-18 10:20 ` Stefan Hajnoczi
2019-11-20 10:11 ` Tomasz Figa
[not found] ` <CAEkmjvU8or7YT7CCBe7aUx-XQ3yJpUrY4CfBOnqk7pUH9d9RGQ@mail.gmail.com>
2019-11-20 11:58 ` Tomasz Figa
2019-11-20 12:11 ` Tomasz Figa
2019-11-11 3:04 ` David Stevens
2019-11-11 15:36 ` [virtio-dev] " Liam Girdwood
2019-11-12 0:54 ` Gurchetan Singh
2019-11-12 13:56 ` Liam Girdwood
2019-11-12 22:55 ` Gurchetan Singh
2019-11-19 15:31 ` Liam Girdwood
2019-11-20 0:42 ` Gurchetan Singh
2019-11-20 9:53 ` Gerd Hoffmann
2019-11-25 16:46 ` Liam Girdwood
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='CAD=HUj7EsxrkSubmY6HE4aYJOykVKtmGXjMjeGqnoJw1KZUc5Q@mail.gmail.com' \
--to=stevensd@chromium.org \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).