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

[Daniel P . Berrangé]

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. 

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