From: Dylan Reid <email@example.com> To: Tomasz Figa <firstname.lastname@example.org>, Zach Reizner <email@example.com> Cc: "Geoffrey McRae" <firstname.lastname@example.org>, "Gerd Hoffmann" <email@example.com>, "David Stevens" <firstname.lastname@example.org>, "Keiichi Watanabe" <email@example.com>, "Dmitry Morozov" <firstname.lastname@example.org>, "Alexandre Courbot" <email@example.com>, "Alex Lau" <firstname.lastname@example.org>, "Stéphane Marchesin" <email@example.com>, "Pawel Osciak" <firstname.lastname@example.org>, "Hans Verkuil" <email@example.com>, "Daniel Vetter" <firstname.lastname@example.org>, "Gurchetan Singh" <email@example.com>, "Linux Media Mailing List" <firstname.lastname@example.org>, email@example.com, qemu-devel <firstname.lastname@example.org> Subject: Re: guest / host buffer sharing ... Date: Thu, 5 Dec 2019 09:22:04 +1100 Message-ID: <CAEUnVG77y2DrV5kLTHDy1xio+yzMGv9j=M0c4388vH_LUaiXLg@mail.gmail.com> (raw) In-Reply-To: <CAAFQd5AWqYaNWfYQ2hepjg7OD8y8ehHn0guusAR8JYefc+BNaw@mail.gmail.com> On Thu, Nov 21, 2019 at 4:59 PM Tomasz Figa <email@example.com> wrote: > > On Thu, Nov 21, 2019 at 6:41 AM Geoffrey McRae <firstname.lastname@example.org> wrote: > > > > > > > > On 2019-11-20 23:13, Tomasz Figa wrote: > > > Hi Geoffrey, > > > > > > On Thu, Nov 7, 2019 at 7:28 AM Geoffrey McRae <email@example.com> > > > wrote: > > >> > > >> > > >> > > >> On 2019-11-06 23:41, Gerd Hoffmann wrote: > > >> > 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. > > >> > > >> The entire point of this for our purposes is due to the fact that we > > >> can > > >> not allocate the buffer, it's either provided by the GPU driver or > > >> DirectX. If virtio-gpu were to allocate the buffer we might as well > > >> forget > > >> all this and continue using the ivshmem device. > > > > > > I don't understand why virtio-gpu couldn't allocate those buffers. > > > Allocation doesn't necessarily mean creating new memory. Since the > > > virtio-gpu device on the host talks to the GPU driver (or DirectX?), > > > why couldn't it return one of the buffers provided by those if > > > BIND_SCANOUT is requested? > > > > > > > Because in our application we are a user-mode application in windows > > that is provided with buffers that were allocated by the video stack in > > windows. We are not using a virtual GPU but a physical GPU via vfio > > passthrough and as such we are limited in what we can do. Unless I have > > completely missed what virtio-gpu does, from what I understand it's > > attempting to be a virtual GPU in its own right, which is not at all > > suitable for our requirements. > > Not necessarily. virtio-gpu in its basic shape is an interface for > allocating frame buffers and sending them to the host to display. > > It sounds to me like a PRIME-based setup similar to how integrated + > discrete GPUs are handled on regular systems could work for you. The > virtio-gpu device would be used like the integrated GPU that basically > just drives the virtual screen. The guest component that controls the > display of the guest (typically some sort of a compositor) would > allocate the frame buffers using virtio-gpu and then import those to > the vfio GPU when using it for compositing the parts of the screen. > The parts of the screen themselves would be rendered beforehand by > applications into local buffers managed fully by the vfio GPU, so > there wouldn't be any need to involve virtio-gpu there. Only the > compositor would have to be aware of it. > > Of course if your guest is not Linux, I have no idea if that can be > handled in any reasonable way. I know those integrated + discrete GPU > setups do work on Windows, but things are obviously 100% proprietary, > so I don't know if one could make them work with virtio-gpu as the > integrated GPU. > > > > > This discussion seems to have moved away completely from the original > > simple feature we need, which is to share a random block of guest > > allocated ram with the host. While it would be nice if it's contiguous > > ram, it's not an issue if it's not, and with udmabuf (now I understand > > it) it can be made to appear contigous if it is so desired anyway. > > > > vhost-user could be used for this if it is fixed to allow dynamic > > remapping, all the other bells and whistles that are virtio-gpu are > > useless to us. > > > > As far as I followed the thread, my impression is that we don't want > to have an ad-hoc interface just for sending memory to the host. The > thread was started to look for a way to create identifiers for guest > memory, which proper virtio devices could use to refer to the memory > within requests sent to the host. > > That said, I'm not really sure if there is any benefit of making it > anything other than just the specific virtio protocol accepting > scatterlist of guest pages directly. > > Putting the ability to obtain the shared memory itself, how do you > trigger a copy from the guest frame buffer to the shared memory? Adding Zach for more background on virtio-wl particular use cases.
next prev parent reply index Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-05 10:54 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 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 [this message] 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 publically 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='CAEUnVG77y2DrV5kLTHDy1xio+yzMGv9j=M0c4388vH_LUaiXLg@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
Linux-Media Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \ firstname.lastname@example.org public-inbox-index linux-media Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media AGPL code for this site: git clone https://public-inbox.org/public-inbox.git