From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAIVf-0005KQ-Am for qemu-devel@nongnu.org; Tue, 07 Jun 2016 11:01:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAIVa-0000XN-Dh for qemu-devel@nongnu.org; Tue, 07 Jun 2016 11:01:39 -0400 Received: from mx5-phx2.redhat.com ([209.132.183.37]:39322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAIVa-0000XA-5d for qemu-devel@nongnu.org; Tue, 07 Jun 2016 11:01:34 -0400 Date: Tue, 7 Jun 2016 11:01:31 -0400 (EDT) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <1998577010.4328652.1465311691704.JavaMail.zimbra@redhat.com> In-Reply-To: <1465310827.14901.104.camel@redhat.com> References: <1465076003-26291-1-git-send-email-marcandre.lureau@redhat.com> <1465310827.14901.104.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 00/14] vhost-user backends for gpu & input virtio devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , QEMU , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Hi ----- Original Message ----- > On Mo, 2016-06-06 at 15:54 +0200, Marc-Andr=C3=A9 Lureau wrote: > > Hi Gerd > >=20 > > 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. > >=20 > > 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 >=20 > 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). >=20 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) >=20 > Indeed. Doing a "mouse wiggler" would be a pretty minimal backend. >=20 > > - 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 >=20 > 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 return= s the array of virtio_input_config, that is later read via virtio config se= lection. 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. >=20 > 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. >=20 > > 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. >=20 > 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 th= e vhost-gpu backend once the channel is up and the gpu is active. Eventuall= y 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?) =20 > 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 p= rocess. > > Going further, once we have proper reconnect & reset support in > > vhost-user & virtio, one can imagine running/stoping different UIs > > too. >=20 > 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