From nobody Mon Feb 9 06:34:15 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1495057772831512.7700184886035; Wed, 17 May 2017 14:49:32 -0700 (PDT) Received: from localhost ([::1]:50884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB6p1-0004ES-H2 for importer@patchew.org; Wed, 17 May 2017 17:49:31 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB6kw-0000ny-N5 for qemu-devel@nongnu.org; Wed, 17 May 2017 17:45:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB6kv-0005MM-5D for qemu-devel@nongnu.org; Wed, 17 May 2017 17:45:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35720) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dB6ku-0005M7-T4; Wed, 17 May 2017 17:45:17 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC7C07F7A7; Wed, 17 May 2017 21:45:15 +0000 (UTC) Received: from redhat.com (ovpn-120-251.rdu2.redhat.com [10.10.120.251]) by smtp.corp.redhat.com (Postfix) with ESMTP id A2BDE1714D; Wed, 17 May 2017 21:45:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BC7C07F7A7 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mst@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BC7C07F7A7 Date: Thu, 18 May 2017 00:45:11 +0300 From: "Michael S. Tsirkin" To: qemu-devel@nongnu.org Message-ID: <1495057396-13387-4-git-send-email-mst@redhat.com> References: <1495057396-13387-1-git-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1495057396-13387-1-git-send-email-mst@redhat.com> X-Mutt-Fcc: =sent X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 17 May 2017 21:45:15 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 03/13] hw/virtio: fix vhost user fails to startup when MQ X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Zhiyong Yang , qemu-stable@nongnu.org, Jens Freimann , Maxime Coquelin , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" From: Zhiyong Yang Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together to cause failures of new connection when negotiating to set MQ. (one queue pair works well). Because there exist some bugs in qemu code when introducing VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. When vhost_user_set_mem_table is invoked to deal with the vhost message VHOST_USER_SET_MEM_TABLE for the second time, qemu indeed doesn't send the messge (The message needs to be sent only once)but still will be waiting for dpdk's reply ack, then, qemu is always freezing, while DPDK is always waiting for next vhost message from qemu. The patch aims to fix the bug, MQ can work well. The same bug is found in function vhost_user_net_set_mtu, it is fixed at the same time. DPDK related patch is as following: http://www.dpdk.org/dev/patchwork/patch/23955/ Signed-off-by: Zhiyong Yang Cc: qemu-stable@nongnu.org Fixes: ca525ce5618b ("vhost-user: Introduce a new protocol feature REPLY_AC= K.") Reviewed-by: Maxime Coquelin Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Tested-by: Jens Freimann Reviewed-by: Marc-Andr=C3=A9 Lureau --- hw/virtio/vhost-user.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 9334a8a..32a95a8 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -163,22 +163,26 @@ fail: } =20 static int process_message_reply(struct vhost_dev *dev, - VhostUserRequest request) + VhostUserMsg msg) { - VhostUserMsg msg; + VhostUserMsg msg_reply; =20 - if (vhost_user_read(dev, &msg) < 0) { + if ((msg.flags & VHOST_USER_NEED_REPLY_MASK) =3D=3D 0) { + return 0; + } + + if (vhost_user_read(dev, &msg_reply) < 0) { return -1; } =20 - if (msg.request !=3D request) { + if (msg_reply.request !=3D msg.request) { error_report("Received unexpected msg type." "Expected %d received %d", - request, msg.request); + msg.request, msg_reply.request); return -1; } =20 - return msg.payload.u64 ? -1 : 0; + return msg_reply.payload.u64 ? -1 : 0; } =20 static bool vhost_user_one_time_request(VhostUserRequest request) @@ -208,6 +212,7 @@ static int vhost_user_write(struct vhost_dev *dev, Vhos= tUserMsg *msg, * request, we just ignore it. */ if (vhost_user_one_time_request(msg->request) && dev->vq_index !=3D 0)= { + msg->flags &=3D ~VHOST_USER_NEED_REPLY_MASK; return 0; } =20 @@ -320,7 +325,7 @@ static int vhost_user_set_mem_table(struct vhost_dev *d= ev, } =20 if (reply_supported) { - return process_message_reply(dev, msg.request); + return process_message_reply(dev, msg); } =20 return 0; @@ -712,7 +717,7 @@ static int vhost_user_net_set_mtu(struct vhost_dev *dev= , uint16_t mtu) =20 /* If reply_ack supported, slave has to ack specified MTU is valid */ if (reply_supported) { - return process_message_reply(dev, msg.request); + return process_message_reply(dev, msg); } =20 return 0; --=20 MST