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