From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGZpA-00036K-7G for qemu-devel@nongnu.org; Fri, 24 Jun 2016 18:43:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGZp4-0004C0-Cu for qemu-devel@nongnu.org; Fri, 24 Jun 2016 18:43:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGZp4-0004BF-7I for qemu-devel@nongnu.org; Fri, 24 Jun 2016 18:43:38 -0400 Date: Sat, 25 Jun 2016 01:43:33 +0300 From: "Michael S. Tsirkin" Message-ID: <20160625014043-mutt-send-email-mst@redhat.com> References: <1466756228-27490-1-git-send-email-saxenap.ltc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466756228-27490-1-git-send-email-saxenap.ltc@gmail.com> 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: qemu-devel@nongnu.org, Prerna Saxena , anilkumar.boggarapu@nutanix.com, felipe.francoisi@nutanix.com On Fri, Jun 24, 2016 at 01:17:07AM -0700, Prerna Saxena wrote: > From: Prerna Saxena > > The current vhost-user protocol requires the client to send responses 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 spec. > (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 know about those GPAs OK, but there's a simple way to fix the race: submit another request e.g. GET_FEATURES and wait for a response. > > Note that the kernel implementation does not suffer from this limitation 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 existing applications. This patch introduces a protocol extension, VHOST_USER_PROTOCOL_F_REPLY_ACK. This feature, if negotiated, allows QEMU to annotate messages to the application that it seeks a response for. The application must then respond to qemu by providing a status about the requested operation. I would like this structured like this: 1. fix races by sending GET_FEATURES and waiting for it 2. add VHOST_USER_PROTOCOL_F_REPLY_ACK > > Prerna Saxena (1): > vhost-user : Introduce a new feature, VHOST_USER_PROTOCOL_F_REPLY_ACK > This feature, if negotiated, forces the remote vhost-user > process to send a u64 reply containin status code for each > requested operation. > Status codes are '0' for success, and non-zero for error. > > docs/specs/vhost-user.txt | 36 +++++++++++ > hw/virtio/vhost-user.c | 153 +++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 186 insertions(+), 3 deletions(-) > > -- > 1.8.1.2 >