[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 00/14] vhost-user backends for gpu & input virtio
Re: [Qemu-devel] [RFC 00/14] vhost-user backends for gpu & input virtio devices
Tue, 07 Jun 2016 16:47:07 +0200
On Mo, 2016-06-06 at 15:54 +0200, Marc-André Lureau wrote:
> 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
Which implies a 1:1 relationship between object and backend. Which
isn't that great if we want allow for multiple backends in one process
(your idea below, and I think it can be useful).
> - "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)
Indeed. Doing a "mouse wiggler" would be a pretty minimal backend.
> - 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
Is that needed? I think it should be possible to create device-agnostic
messages for config access.
> - 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
I would tend to send it all over the same 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.
Interesting idea, would safe quite a few context switches for dma-buf
passing. But it also brings new challenges, vga compatibility for
example. Also spice channel management. vdagent, ...
I'd suggest put it aside for now though. Get the other stuff done
first. Running virglrenderer in a separate process is certainly very
useful from a security point of view, and that is a big enough project
for a while I suspect.
> Going further, once we have proper reconnect & reset support in
> vhost-user & virtio, one can imagine running/stoping different UIs
That'll be quite difficult for virtio-gpu too.
virtio-input should be easy though.
- Re: [Qemu-devel] [RFC 05/14] Add vhost-user backend to virtio-input-host, (continued)
- [Qemu-devel] [RFC 08/14] vhost: make sure call fd has been received, marcandre . lureau, 2016/06/04
- [Qemu-devel] [RFC 06/14] contrib: add vhost-user-input, marcandre . lureau, 2016/06/04
- [Qemu-devel] [RFC 10/14] qemu-char: block during sync read, marcandre . lureau, 2016/06/04
- [Qemu-devel] [RFC 12/14] contrib: add vhost-user-gpu, marcandre . lureau, 2016/06/04
- [Qemu-devel] [RFC 13/14] vhost-user: add vhost_user_gpu_set_socket(), marcandre . lureau, 2016/06/04
- [Qemu-devel] [RFC 14/14] Add virtio-gpu vhost-user backend, marcandre . lureau, 2016/06/04
- Re: [Qemu-devel] [RFC 00/14] vhost-user backends for gpu & input virtio devices, Marc-André Lureau, 2016/06/06
- Re: [Qemu-devel] [RFC 00/14] vhost-user backends for gpu & input virtio devices,
Gerd Hoffmann <=