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 DC8D0E72 for ; Tue, 27 Oct 2015 10:42:27 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 23E588EA35; Tue, 27 Oct 2015 09:42:27 +0000 (UTC) Received: from redhat.com (ovpn-116-58.ams2.redhat.com [10.36.116.58]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t9R9gOov016455; Tue, 27 Oct 2015 05:42:25 -0400 Date: Tue, 27 Oct 2015 11:42:24 +0200 From: "Michael S. Tsirkin" To: Yuanhan Liu Message-ID: <20151027113807-mutt-send-email-mst@redhat.com> References: <1445399294-18826-1-git-send-email-yuanhan.liu@linux.intel.com> <1445517356-19780-1-git-send-email-yuanhan.liu@linux.intel.com> <1445517356-19780-4-git-send-email-yuanhan.liu@linux.intel.com> <562DB8F8.4050707@igel.co.jp> <20151026054215.GY3115@yliu-dev.sh.intel.com> <562F17B8.5020107@igel.co.jp> <20151027111444-mutt-send-email-mst@redhat.com> <20151027093041.GI3115@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151027093041.GI3115@yliu-dev.sh.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: dev@dpdk.org, marcel@redhat.com Subject: Re: [dpdk-dev] [PATCH v8 3/8] vhost: vring queue setup for multiple queue support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:42:28 -0000 On Tue, Oct 27, 2015 at 05:30:41PM +0800, Yuanhan Liu wrote: > On Tue, Oct 27, 2015 at 11:17:16AM +0200, Michael S. Tsirkin wrote: > > On Tue, Oct 27, 2015 at 03:20:40PM +0900, Tetsuya Mukawa wrote: > > > On 2015/10/26 14:42, Yuanhan Liu wrote: > > > > On Mon, Oct 26, 2015 at 02:24:08PM +0900, Tetsuya Mukawa wrote: > > > >> On 2015/10/22 21:35, Yuanhan Liu wrote: > > > > ... > > > >>> @@ -292,13 +300,13 @@ user_get_vring_base(struct vhost_device_ctx ctx, > > > >>> * sent and only sent in vhost_vring_stop. > > > >>> * TODO: cleanup the vring, it isn't usable since here. > > > >>> */ > > > >>> - if ((dev->virtqueue[VIRTIO_RXQ]->kickfd) >= 0) { > > > >>> - close(dev->virtqueue[VIRTIO_RXQ]->kickfd); > > > >>> - dev->virtqueue[VIRTIO_RXQ]->kickfd = -1; > > > >>> + if ((dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ) >= 0) { > > > >>> + close(dev->virtqueue[state->index + VIRTIO_RXQ]->kickfd); > > > >>> + dev->virtqueue[state->index + VIRTIO_RXQ]->kickfd = -1; > > > >>> } > > > >> Hi Yuanhan, > > > >> > > > >> Please let me make sure whether below is correct. > > > >> if ((dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ) >= 0) { > > > >> > > > >>> - if ((dev->virtqueue[VIRTIO_TXQ]->kickfd) >= 0) { > > > >>> - close(dev->virtqueue[VIRTIO_TXQ]->kickfd); > > > >>> - dev->virtqueue[VIRTIO_TXQ]->kickfd = -1; > > > >>> + if ((dev->virtqueue[state->index]->kickfd + VIRTIO_TXQ) >= 0) { > > > >>> + close(dev->virtqueue[state->index + VIRTIO_TXQ]->kickfd); > > > >>> + dev->virtqueue[state->index + VIRTIO_TXQ]->kickfd = -1; > > > >> Also, same question here. > > > > Oops, silly typos... Thanks for catching it out! > > > > > > > > Here is an update patch (Thomas, please let me know if you prefer me > > > > to send the whole patchset for you to apply): > > > > > > Hi Yuanhan, > > > > > > I may miss one more issue here. > > > Could you please see below patch I've submitted today? > > > (I may find a similar issue, so I've fixed it also in below patch.) > > > > > > - http://dpdk.org/dev/patchwork/patch/8038/ > > > > > > Thanks, > > > Tetsuya > > > > Looking at that, at least when MQ is enabled, please don't key > > stopping queues off GET_VRING_BASE. > > Yes, that's only a workaround. I guess it has been there for quite a > while, maybe at the time qemu doesn't send RESET_OWNER message. RESET_OWNER was a bad idea since it basically closes everything. > > There are ENABLE/DISABLE messages for that. > > That's something new, That's part of multiqueue support. If you ignore them, nothing works properly. > though I have plan to use them instead, we still > need to make sure our code work with old qemu, without ENABLE/DISABLE > messages. OK but don't rely on this for new code. > And I will think more while enabling live migration: I should have > more time to address issues like this at that time. > > > Generally guys, don't take whatever QEMU happens to do for > > granted! Look at the protocol spec under doc/specs directory, > > if you are making more assumptions you must document them! > > Indeed. And we will try to address them bit by bit in future. > > --yliu But don't pile up these workarounds meanwhile. I'm very worried. The way you are carrying on, each new QEMU is likely to break your assumptions. -- MST