qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: David Stevens <stevensd@chromium.org>
Cc: geoff@hostfission.com, "Hans Verkuil" <hverkuil@xs4all.nl>,
	"Alex Lau" <alexlau@chromium.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.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, 6 Nov 2019 13:41:01 +0100	[thread overview]
Message-ID: <20191106124101.fsfxibdkypo4rswv@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAD=HUj7EsxrkSubmY6HE4aYJOykVKtmGXjMjeGqnoJw1KZUc5Q@mail.gmail.com>

On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote:
> > (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.

If there are additional constrains (due to gpu hardware I guess)
I think it is better to leave the buffer allocation to virtio-gpu.

virtio-gpu can't do that right now, but we have to improve virtio-gpu
memory management for vulkan support anyway.

> > properties to carry metadata, some fixed (id, size, application), but
> 
> What exactly do you mean by application?

Basically some way to group buffers.  A wayland proxy for example would
add a "application=wayland-proxy" tag to the buffers it creates in the
guest, and the host side part of the proxy could ask qemu (or another
vmm) to notify about all buffers with that tag.  So in case multiple
applications are using the device in parallel they don't interfere with
each other.

> > 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?

No parameter negotiation.

cheers,
  Gerd



  reply	other threads:[~2019-11-06 12:42 UTC|newest]

Thread overview: 52+ 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
2019-11-06 12:41   ` Gerd Hoffmann [this message]
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-07 15:10           ` Frank Yang
2019-11-20 11:58             ` Tomasz Figa
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
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=20191106124101.fsfxibdkypo4rswv@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 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).