From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGaIN-0001Wa-H8 for qemu-devel@nongnu.org; Fri, 24 Jun 2016 19:13:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGaIJ-00086N-70 for qemu-devel@nongnu.org; Fri, 24 Jun 2016 19:13:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGaII-000867-NT for qemu-devel@nongnu.org; Fri, 24 Jun 2016 19:13:50 -0400 Date: Sat, 25 Jun 2016 02:13:47 +0300 From: "Michael S. Tsirkin" Message-ID: <20160625021320-mutt-send-email-mst@redhat.com> References: <1466756228-27490-1-git-send-email-saxenap.ltc@gmail.com> <3CF88E3C-DAF6-4052-B8AB-0A7AE3C2F45D@nutanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3CF88E3C-DAF6-4052-B8AB-0A7AE3C2F45D@nutanix.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/1] vhost-user: Add a protocol extension for client responses to vhost commands. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Prerna Saxena Cc: Felipe Franciosi , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , Prerna Saxena , Anil Kumar Boggarapu , QEMU On Fri, Jun 24, 2016 at 05:39:31PM +0000, Prerna Saxena wrote: >=20 >=20 > On 24/06/16 9:15 pm, "Felipe Franciosi" wrote: >=20 > >We talked to MST on IRC a while back and he brainstormed the idea of d= oing this per-message. > >(I even recall proposing to call this feature REPLY_ALL and he suggest= ed REPLY_ANY due to that.) > > > >I agree with doing it per message, as the protocol itself should be fl= exible in that sense. > >(Even if qemu today will probably want to ask for a reply in all messa= ges.) >=20 > In fact, the current implementation does exactly this. If VHOST_USER_PR= OTOCOL_F_REPLY_ACK is negotiated, the current QEMU patch sets the NEED_RE= SPONSE flag bit for all outgoing messages =E2=80=94 basically enforcing t= he vhost-user application to respond to all messages. This seems unnecessary. Let's only do that for messages that actually need to be synchronous. > > > >On 24/06/2016, 14:59, "Qemu-devel on behalf of Marc-Andr=C3=A9 Lureau"= wrote: > > > >Hi > > > >On Fri, Jun 24, 2016 at 10:17 AM, Prerna Saxena wrote: > >> From: Prerna Saxena > >> > >> The current vhost-user protocol requires the client to send response= s to only few commands. For the remaining commands, it is impossible for = QEMU to know the status of the requested operation -- ie, did it succeed = at all, and if so, at what time. > >> > >> This is inconvenient, and can also lead to races. As an example: > >> > >> (1) qemu sends a SET_MEM_TABLE to the backend (eg, a vhost-user net = application) and SET_MEM_TABLE doesn't require a reply according to the s= pec. > >> (2) qemu commits the memory to the guest. > >> (3) guest issues an I/O operation over a new memory region which was= configured on (1) > >> (4) The application hasn't yet remapped the memory, but it sees the = I/O request. > >> (5) The application cannot satisfy the request because it doesn't kn= ow about those GPAs > >> > >> Note that the kernel implementation does not suffer from this limita= tion since messages are sent via an ioctl(). The ioctl() blocks until the= backend (eg. vhost-net) completes the command and returns (with an error= code). > >> > >> Changing the behaviour of current vhost-user commands would break ex= isting applications. This patch introduces a protocol extension, VHOST_US= ER_PROTOCOL_F_REPLY_ACK. This feature, if negotiated, allows QEMU to anno= tate messages to the application that it seeks a response for. The applic= ation must then respond to qemu by providing a status about the requested= operation. > > > >I like the idea, as I encountered a similar issue in my > >"vhost-user-gpu" development (which I worked around by sending a dump > >GET_FEATURES.. to sync things). But I question the need to have a flag > >per message. I think if the protocol feature is negociated, all > >messages should have a reply. Why do you want it to be per-message? > > > >thanks > > > >--=20 > >Marc-Andr=C3=A9 Lureau > > > > > >