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
