From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bY6Do-0001ET-Gj for qemu-devel@nongnu.org; Fri, 12 Aug 2016 02:45:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bY6Dk-0003Uc-Dz for qemu-devel@nongnu.org; Fri, 12 Aug 2016 02:45:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bY6Dk-0003UW-3A for qemu-devel@nongnu.org; Fri, 12 Aug 2016 02:45:32 -0400 Date: Fri, 12 Aug 2016 14:38:28 +0800 From: Fam Zheng Message-ID: <20160812063828.GG2759@al.usersys.redhat.com> References: <1470842980-32481-1-git-send-email-mst@redhat.com> <1470842980-32481-4-git-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1470842980-32481-4-git-send-email-mst@redhat.com> Subject: Re: [Qemu-devel] [PULL 3/3] vhost-user: Attempt to fix a race with set_mem_table. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Peter Maydell , Prerna Saxena On Wed, 08/10 18:30, Michael S. Tsirkin wrote: > From: Prerna Saxena > > The set_mem_table command currently does not seek a reply. Hence, there is > no easy way for a remote application to notify to QEMU when it finished > setting up memory, or if there were errors doing so. > > As an example: > (1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost-user net > application). SET_MEM_TABLE does not 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 has not yet remapped the memory, but it sees the I/O request. > (5) The application cannot satisfy the request because it does not know about those GPAs. > > While a guaranteed fix would require a protocol extension (committed separately), > a best-effort workaround for existing applications is to send a GET_FEATURES > message before completing the vhost_user_set_mem_table() call. > Since GET_FEATURES requires a reply, an application that processes vhost-user > messages synchronously would probably have completed the SET_MEM_TABLE before replying. > > Signed-off-by: Prerna Saxena > Reviewed-by: Michael S. Tsirkin > Signed-off-by: Michael S. Tsirkin Sporadic hangs are seen with test-vhost-user after this patch: https://travis-ci.org/qemu/qemu/builds Reverting seems to fix it for me. Is this a known problem? Fam