Re: [Qemu-devel] [RFC 00/14] vhost-user backends for gpu & input virtio devices

[Marc-André Lureau]

Hi Gerd

Thanks for your feedback on the series. Your remarks are all valid,
but before doing more work I would like to know if there is enough
interest. It duplicates work and adds some complexity. Also, some
general feedback on design would be welcome.

What is proposed in this series:
- the vhost-user-backend is a helper object spawning, setting up and
holding a connection to a backend
- the vhost-user socket is set to be fd 3 in child process
- we may want to use only or allow specifying a unix socket chardev to
a backend (like vhost-net), in which case management of backend would
be left outside of qemu
- "add vhost-user backend to virtio-input-host" patch shows how little
is required for a virtio device to use vhost-user-backend, and is
quite a neat use case imho (allowing various input backends)
- there are device specific vhost-user messages to be added, such as
VHOST_USER_INPUT_GET_CONFIG, or we may use extra fd for communication
to pass to child during fork
- when there is a whole set of messages to add, like the VHOST_GPU*, I
decided to use a different socket, given to backend with
VHOST_USER_GPU_SET_SOCKET.

I am not sold that we need to develop a new vhost protocol for the gpu
though. I am considering the Spice worker thread (handling cursor and
display) to actually run in the vhost backend. That would make the
solution Spice specific though (unless qemu implements some of the
Spice protocol ...). Having the spice worker running in the backend
has similar advantages of robustness to reduce attack to qemu by a
spice user.

I am also wondering if several virtio backends could be combined in
the same process. This would allow to have quite easily qemu gtk/sdl
UI in a subprocess.

Going further, once we have proper reconnect & reset support in
vhost-user & virtio, one can imagine running/stoping different UIs
too.

(so after this initial rfc, that look all nice to me, the question I
ask myself is what do we actually want?)

-- 
Marc-André Lureau