* Daniel P. Berrangé (berra...@redhat.com) 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 / dgilb...@redhat.com / Manchester, UK
