From patchwork Thu May 28 09:03:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Coquelin X-Patchwork-Id: 70679 X-Patchwork-Delegate: maxime.coquelin@redhat.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1BDB2A00BE; Thu, 28 May 2020 11:04:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6052D1DB59; Thu, 28 May 2020 11:04:04 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 9762D1DB35 for ; Thu, 28 May 2020 11:04:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590656641; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=X8cRr1P+gjvF6rNVLEmMuANd4ErP4PEnmqlQixY8lD8=; b=DN1J8irDIhbYadzARIXoXQyZrB72/t6ZFyOnOi8J0XesilSCWdl1ZOb71/mlRHypB0mY68 spp1x93L1dL7pYaN0mFgT8tmWOABmZ88F29/M1J8TuzJkES6vPj6bOS3hCLysJwFzhbkrJ aC4MbDHPmhUzW9KAslN1RuKxOxiKNTU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-471-n1T6RiSnNJ6wER2UaIMJhg-1; Thu, 28 May 2020 05:03:59 -0400 X-MC-Unique: n1T6RiSnNJ6wER2UaIMJhg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 49EFC800D24; Thu, 28 May 2020 09:03:58 +0000 (UTC) Received: from localhost.localdomain (unknown [10.36.110.21]) by smtp.corp.redhat.com (Postfix) with ESMTP id 295A15D9F3; Thu, 28 May 2020 09:03:50 +0000 (UTC) From: Maxime Coquelin To: dev@dpdk.org, xiaolong.ye@intel.com, amorenoz@redhat.com, david.marchand@redhat.com, thomas@monjalon.net Cc: Maxime Coquelin Date: Thu, 28 May 2020 11:03:47 +0200 Message-Id: <20200528090347.441445-1-maxime.coquelin@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Subject: [dpdk-dev] [PATCH v2] vhost: enable reply-ack systematically X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" As announced during v20.05 release cycle, this patch makes reply-ack protocol feature to be enabled unconditionally. This protocol feature makes the communication between the master and the slave more robust, avoiding for example possible undefined behaviour with VHOST_USER_SET_MEM_TABLE. Also, reply-ack support will be required for upcoming VHOST_USER_SET_STATUS request. Note that this protocol feature was disabled by default because Qemu version 2.7.0 to 2.9.0 had a bug causing a deadlock when reply-ack was negotiated and multiqueue enabled. These Qemu version are now very old and no more maintained, so we can resonnably consider we no more support them. Signed-off-by: Maxime Coquelin Reviewed-by: Chenbo Xia --- v2: - Fix commit message - Remove mention to the workaround in the doc doc/guides/prog_guide/vhost_lib.rst | 5 ----- lib/librte_vhost/vhost_user.c | 9 --------- 2 files changed, 14 deletions(-) diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst index 07e40e3c5e..db921f922b 100644 --- a/doc/guides/prog_guide/vhost_lib.rst +++ b/doc/guides/prog_guide/vhost_lib.rst @@ -104,11 +104,6 @@ The following is an overview of some key Vhost API functions: from accessing memory the virtio device isn't allowed to, when the feature is negotiated and an IOMMU device is declared. - However, this feature enables vhost-user's reply-ack protocol feature, - which implementation is buggy in Qemu v2.7.0-v2.9.0 when doing multiqueue. - Enabling this flag with these Qemu version results in Qemu being blocked - when multiple queue pairs are declared. - - ``RTE_VHOST_USER_POSTCOPY_SUPPORT`` Postcopy live-migration support will be enabled when this flag is set. diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c index 84bebad792..ea9cd107b9 100644 --- a/lib/librte_vhost/vhost_user.c +++ b/lib/librte_vhost/vhost_user.c @@ -2012,15 +2012,6 @@ vhost_user_get_protocol_features(struct virtio_net **pdev, rte_vhost_driver_get_features(dev->ifname, &features); rte_vhost_driver_get_protocol_features(dev->ifname, &protocol_features); - /* - * REPLY_ACK protocol feature is only mandatory for now - * for IOMMU feature. If IOMMU is explicitly disabled by the - * application, disable also REPLY_ACK feature for older buggy - * Qemu versions (from v2.7.0 to v2.9.0). - */ - if (!(features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))) - protocol_features &= ~(1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK); - msg->payload.u64 = protocol_features; msg->size = sizeof(msg->payload.u64); msg->fd_num = 0;