From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 53BE95A65 for ; Tue, 27 Oct 2015 10:52:03 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 27 Oct 2015 02:52:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,204,1444719600"; d="scan'208";a="588793206" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 27 Oct 2015 02:52:01 -0700 Date: Tue, 27 Oct 2015 17:53:20 +0800 From: Yuanhan Liu To: "Michael S. Tsirkin" Message-ID: <20151027095320.GM3115@yliu-dev.sh.intel.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> <20151027113807-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151027113807-mutt-send-email-mst@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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:52:03 -0000 On Tue, Oct 27, 2015 at 11:42:24AM +0200, Michael S. Tsirkin wrote: ... > > > 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. I will handle them shortly. (well, it may still need weeks :( > > 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. Yes. > > > 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. Good point. I'll have more discussion with Huawei, to see if we can fix them sooner. --yliu