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

[Daniel P . Berrangé]

On Wed, Aug 29, 2018 at 11:22:01AM +0100, Dr. David Alan Gilbert wrote:
> * 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.

We can still do both - the simple case where QEMU just spawns a process,

  $ qemu...
    -device virtio-vga

while also allowing connections to a pre-spawned process to have extra
privs via:

  $ qemu...
    -device virtio-vga,vhost=chardevID

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