From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAavF-0003QC-AJ for qemu-devel@nongnu.org; Wed, 08 Jun 2016 06:41:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAavA-0005uy-AY for qemu-devel@nongnu.org; Wed, 08 Jun 2016 06:41:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAavA-0005uu-2W for qemu-devel@nongnu.org; Wed, 08 Jun 2016 06:41:12 -0400 Message-ID: <1465366312.23509.23.camel@redhat.com> From: Gerd Hoffmann In-Reply-To: <1998577010.4328652.1465311691704.JavaMail.zimbra@redhat.com> References: <1465076003-26291-1-git-send-email-marcandre.lureau@redhat.com> <1465310827.14901.104.camel@redhat.com> <1998577010.4328652.1465311691704.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 08 Jun 2016 08:11:52 +0200 Mime-Version: 1.0 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: =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau Cc: =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau , QEMU , =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau On Di, 2016-06-07 at 11:01 -0400, Marc-Andr=C3=A9 Lureau wrote: > Hi >=20 > ----- 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 >=20 > That socket could use a different protocol to instantiate vhost-user devi= ce/backends (passing vhost-user sockets per device)? I'd tend to simply hand the backend process one unix socket path per device. Maybe also allow libvirt to link things using monitor fd passing. It's a little less automatic, but more flexible. > > > - 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-agnosti= c > > messages for config access. >=20 > 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? Well, not as one-time init call. You have to forward every write access to the backend. For read access the easiest would be to forward every access too. Or have a shadow copy for read access which is updated after every write. > > > - 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. >=20 > 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. Ok. So maybe it isn't that useful to use vhost-user for the gpu? The fundamental issue here is that qemu needs to process some of the messages. So you send those back to qemu via VHOST_GPU*. So maybe it works better when we continue to terminate the rings in qemu, then forward messages relevant for virglrenderer to the external process. > > > I am not sold that we need to develop a new vhost protocol for the gp= u > > > 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, ... >=20 > 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?) It's not clear to me how you want hand over the display channel from qemu (and spice-server running as thread in qemu process context) to the vhost backend (running in a separate process). cheers, Gerd