qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU
Date: Wed, 29 Aug 2018 11:22:01 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

* Daniel P. Berrangé (address@hidden) wrote:
> On Fri, Jul 13, 2018 at 03:08:47PM +0200, Marc-André Lureau wrote:
> > Hi,
> > 
> > vhost-user allows to drive a virtio device in a seperate
> > process. After vhost-user-net, we have seen
> > vhost-user-{scsi,blk,crypto} added more recently.
> > 
> > This series, initially proposed 2 years ago
> > (https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01905.html)
> > contributes with vhost-user-input and vhost-user-gpu.
> > 
> > Additionally, to factor out common code and ease the usage, a
> > vhost-user-backend is introduced as an intermediary object between the
> > backend and the qemu device.
> > 
> > You may start a vhost-user-gpu with virgl rendering in a separate
> > process like this:
> > 
> > $ ./vhost-user-gpu --virgl -s vgpu.sock &
> > $ qemu...
> >   -chardev socket,id=chr,path=vgpu.sock
> >   -object vhost-user-backend,id=vug,chardev=chr
> >   -device vhost-user-vga,vhost-user=vug
> > 
> > You may also specify the backend command and the arguments as part of
> > vhost-user-backend qemu arguments. For example, to start a
> > vhost-user-input backend on input device /dev/input/event19:
> > 
> > -object vhost-user-backend,id=vuid,cmd="vhost-user-input /dev/input/event19"
> > -device virtio-input-host-pci,vhost-user=vuid
> > 
> > The vhost-user-gpu backend requires virgl from git.
> > 
> > The libvirt support is on-going work:
> > https://github.com/elmarco/libvirt/commits/vhost-user-gpu
> > 
> > The GPU benchmarks are encouraging, giving up to x5 performance on
> > Unigine Heaven 4.0.
> 
> What is the main driving motivation behind this featureset ? Is it aimed
> at providing performance, or security, or allowing arbitrary out of tree
> backends, or all three ?
> 
> Although we've got a number of vhost-user backends I'm pretty concerned
> about the direction this is taking QEMU overall.
> 
> Managing QEMU is non-trivial for a number of reasons. We've done a lot of
> work to provide standardized modelling of CLI args, guest ABI stability
> via association with machine types, migration data stream stability,
> QEMU feature capabilities detection and so on.
> 
> The move to outsource backends to external binaries is discarding some
> or all of these items, rewinding alot of progress we've made in the
> managability of QEMU. Each external binary has to now reinvent the
> things that are already solved in QEMU, and you can be sure each impl
> will reinvent the concepts differently.
> 
> I can't help feeling that we are shooting ourselves in the foot here
> long term.
> 
> We've always rejected the idea of having loadable modules in QEMU, but
> as a result we've end up with outsourcing the backend entirely via the
> vhost-user framework, so the end result is even more opaque than if we
> had loadable modules, and is unable to take advantage of our standardized
> modelling frameworks & capabilities :-(
> 
> If we just look at performance & security, and ignore 3rd party impls
> for a minute, I really don't like that to gain perf + security  we have
> to change from:
> 
>  $ qemu...
>    -device virtio-vga
>  
> To
> 
>  $ ./vhost-user-gpu --virgl -s vgpu.sock &
>  $ qemu...
>    -chardev socket,id=chr,path=vgpu.sock
>    -object vhost-user-backend,id=vug,chardev=chr
>    -device vhost-user-vga,vhost-user=vug
> 
> Once we have the ability to run the backend via an external process,
> to gain performance & security benefits, assuming feature parity is
> achieved, I question why anyone would want to continue with the old
> in-process approach ? IOW the goal should be that the original args 
> 
>  $ qemu...
>    -device virtio-vga
> 
> should "do the right thing" to launch the external process when you
> have upgraded to a new enough QEMU, so that everyone immediately
> benefits from the more secure & performant architecture. 

But which external process should it run, under what privilieges
and with sockets placed where?
While it's true it would be good to have a nice simple way, often
the qemu process might not have the privs to run that external process
or know where to put the sockets; that's exactly the type of thing
we're happy to leave to libvirt to wire up.

Dave

> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]