From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f195.google.com (mail-ua0-f195.google.com [209.85.217.195]) by dpdk.org (Postfix) with ESMTP id AC3DC271 for ; Wed, 6 Dec 2017 13:25:43 +0100 (CET) Received: by mail-ua0-f195.google.com with SMTP id v20so2669461uaj.0 for ; Wed, 06 Dec 2017 04:25:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1bYs+3jSZtJlO0KbxCOD7H+PEt57926nhaySyogrGk0=; b=GX2CTBOdybHz1PxDd2GCyxlpCVAASHJ6Zll6+8fET+64UELPFcbaNcvDhjS87Ekhvb JgoA6fKUkP7ZGKGpnQKpDHPB+5CBvDV9odSGQm2Hc+kUE27EXYa2Umf4upsVjVMghX4/ 7lyJainKgSFBxybVoYkRa3QVirEVgV9RZY1jZ13hR0HkrWZkm29AU9LtHYYkDrEpNbel 8pmjcJ8iNg15REfNZhvJyefy769aioipG8cSwcRlwqlkT6H92I+dLZU77Q/nmFOhEwEO dke7IgkRN5r7HlWZvKb5ZATGBzzHh/xNaZCv2sl/MWWuS9YyrQgaLSY5KydQ+DLkV464 I39w== X-Gm-Message-State: AKGB3mLutRNFDrxia7GocpprM6gi41f8B6Q9lhJspyFCFRVt7aKBzT3O cxgLWCyGnjTyRMyBlacZyUYgwJ8oH+WCBcRkNL9PcA== X-Google-Smtp-Source: AGs4zMYuKbbjBtetHMIqiCeP/O3Aql/nYsBtEPqNgdiCRuHS1U/nIDpgjL/Vsmu1NlohpAMJ2pmHoQsuu3nvL7/OteM= X-Received: by 10.176.20.143 with SMTP id d15mr9058636uae.52.1512563142967; Wed, 06 Dec 2017 04:25:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.52.199 with HTTP; Wed, 6 Dec 2017 04:25:42 -0800 (PST) In-Reply-To: <20171206092048.3568-1-maxime.coquelin@redhat.com> References: <20171206092048.3568-1-maxime.coquelin@redhat.com> From: Ladi Prosek Date: Wed, 6 Dec 2017 13:25:42 +0100 Message-ID: To: Maxime Coquelin Cc: dev@dpdk.org, yliu@fridaylinux.org, tiwei.bie@intel.com, jianfeng.tan@intel.com, Laszlo Ersek Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 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: Wed, 06 Dec 2017 12:25:44 -0000 On Wed, Dec 6, 2017 at 10:20 AM, Maxime Coquelin wrote: > Hi, > > This third revision reworks the VQs destruction loop to fixes the > of-by-one error reported by Laszlo. > > 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 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(-) I have verified that it fixes iPXE and that a full-featured virtio-net driver successfully takes over the device using all queues. Haven't tested OVMF but it should be safe to assume that it's fixed as well. Tested-by: Ladi Prosek Thank you! Ladi