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

[Marc-André Lureau]

Hi

On Wed, Aug 29, 2018 at 11:50 AM, 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 ?

Mainly security/stability & performance. Allowing arbitrary out of
tree backends is a bonus for me, I don't care much if we don't allow
it.

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

I have a bit of the same feeling. For ex, I was a bit reluctant having
the TPM emulator as an external process (new protocol, external
binaries, with various management work, "opaque" migration). But in
the end, the integration with libvirt makes thing quite easy for the
user. So I changed a bit my mind, and I think this is one task that
libvirt can be really good at.

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

I agree, that's one of the reason I put together libvhostuser in the
first place. If qemu ships its own backend, there is no reason we
don't share modelling & code etc.

For ex, I hope more vhost-users will use the -object
vhost-user-backend to do basic connection and virtio setup. (in the
series, -gpu and -input, I didn't really investigate -crypto, -net,
-blk etc)

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

That's a bit incovenient for qemu command line users. But who runs
qemu this way but some developers? (others have higher-level scripts /
tools or libvirt)

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


That's not incompatible with having the lengthy version. But this
comes with some downside atm, since migration is not implemented for
ex (for 2d, virgl doesn't have migration).

And seccomp spawn rule disable forking.

And libvirt will probably want to manage the external process for
security/resource/tweaking reasons.

thanks for the feedback!