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

[Marc-André Lureau]

Hi

----- Original Message -----
> 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).
> 

That socket could use a different protocol to instantiate vhost-user 
device/backends (passing vhost-user sockets per device)?

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

VHOST_USER_INPUT_GET_CONFIG is quite virtio-input specific, since it returns 
the array of virtio_input_config, that is later read via virtio config 
selection. Can this be generalized?

> > - 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 would tend to send it all over the same socket.

It's possible, but currently vhost-user protocol is unidirectional 
(master/slave request/reply relationship). The backend cannot easily send 
messages on its own. So beside reinventing some display protocol, it is hard to 
fit in vhost-user socket today.

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

What I had in mind is to hand off only the cursor and display channel to the 
vhost-gpu backend once the channel is up and the gpu is active. Eventually hand 
it back to qemu when switching back to VGA (sounds like it should be doable to 
me, but perhaps not worth it like this?)
 
> 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.

Agree, then it will require the VHOST_GPU_* messages to update qemu&spice 
process.

> > Going further, once we have proper reconnect & reset support in
> > vhost-user & virtio, one can imagine running/stoping different UIs
> > too.
> 
> That'll be quite difficult for virtio-gpu too.
> virtio-input should be easy though.

Right, I wasn't thinking about 3d in this case ;) Although I still hope we can 
get there some day.

thanks