From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 7886C107A for ; Mon, 11 Dec 2017 16:15:37 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C3CD5C119CB4; Mon, 11 Dec 2017 15:15:36 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-42.ams2.redhat.com [10.36.112.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id ADEB75CC3C; Mon, 11 Dec 2017 15:15:29 +0000 (UTC) From: Maxime Coquelin To: dev@dpdk.org, yliu@fridaylinux.org, tiwei.bie@intel.com, jianfeng.tan@intel.com, lprosek@redhat.com, lersek@redhat.com Cc: Maxime Coquelin Date: Mon, 11 Dec 2017 16:14:59 +0100 Message-Id: <20171211151503.19195-1-maxime.coquelin@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 11 Dec 2017 15:15:36 +0000 (UTC) Subject: [dpdk-dev] [PATCH v4 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated 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: , X-List-Received-Date: Mon, 11 Dec 2017 15:15:37 -0000 Hi, This fourth revision fixes patch 1 by not returning early in SET_FEATURE handling if new features bitfield is same as previous one. Indeed, as reported by Tiwei, in case negotiated features is 0, it would return early whereas it should set the Vnet header len. The change consists in returning early when features are equal only when the device is un running state. I did not applied Laszlo's Acked-by and Ladi's Tested-by because of this change. This new iteration has been tested locally using iPXE. Having QEMU started with mq=on but guest driver not negotiating VIRTIO_NET_F_MQ feature ends up in the vhost device to never start. Indeed, more queues are created in the vhost backend than configured. Guest drivers known to not advertise the VIRTIO_NET_F_MQ feature are iPXE and OVMF Virtio-net drivers. Queues are created because before starting the guest, QEMU sends VHOST_USER_SET_VRING_CALL requests for all queues declared in QEMU command line. Also, once Virtio features negotiated, QEMU sends VHOST_USER_SET_VRING_ENABLE requests to disable all but the first queue pair. This series fixes this by destroying all but first queue pair in the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches makes sure that VHOST_USER_SET_FEATURES request doesn't change Virtio features while the device is running, which should never happen as per the Virtio spec. This helps to make sure vitqueues aren't destroyed while being processed, but also protect from other illegal features changes (e.g. VIRTIO_NET_F_MRG_RXBUF). Changes since v3: ================= - Fix Virtio features = 0 case (Tiwei) Changes since v2: ================= - Patch 2: Rework & fix VQs destruction loop (Laszlo) Changes since v1: ================= - Patch 1: shift bits in the right direction (Ladi) Maxime Coquelin (4): vhost: prevent features to be changed while device is running vhost: propagate VHOST_USER_SET_FEATURES handling error vhost: extract virtqueue cleaning and freeing functions vhost: destroy unused virtqueues when multiqueue not negotiated lib/librte_vhost/vhost.c | 22 ++++++++++++---------- lib/librte_vhost/vhost.h | 3 +++ lib/librte_vhost/vhost_user.c | 39 +++++++++++++++++++++++++++++++++++++-- 3 files changed, 52 insertions(+), 12 deletions(-) -- 2.14.3