From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boioJ-0000nw-61 for qemu-devel@nongnu.org; Mon, 26 Sep 2016 23:12:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1boioF-00053z-Vs for qemu-devel@nongnu.org; Mon, 26 Sep 2016 23:11:59 -0400 Received: from mga02.intel.com ([134.134.136.20]:13079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boioF-0004xm-NW for qemu-devel@nongnu.org; Mon, 26 Sep 2016 23:11:55 -0400 Date: Tue, 27 Sep 2016 11:11:58 +0800 From: Yuanhan Liu Message-ID: <20160927031158.GA25823@yliu-dev.sh.intel.com> References: <1474872056-24665-1-git-send-email-yuanhan.liu@linux.intel.com> <1474872056-24665-2-git-send-email-yuanhan.liu@linux.intel.com> <20160926221112-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160926221112-mutt-send-email-mst@kernel.org> Subject: Re: [Qemu-devel] [PATCH 1/2] vhost: enable any layout feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Stephen Hemminger , Maxime Coquelin , dev@dpdk.org, qemu-devel@nongnu.org On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote: > On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote: > > I assume that if using Version 1 that the bit will be ignored Yes, but I will just quote what you just said: what if the guest virtio device is a legacy device? I also gave my reasons in another email why I consistently set this flag: - we have to return all features we support to the guest. We don't know the guest is a modern or legacy device. That means we should claim we support both: VERSION_1 and ANY_LAYOUT. Assume guest is a legacy device and we just set VERSION_1 (the current case), ANY_LAYOUT will never be negotiated. - I'm following the way Linux kernel takes: it also set both features. Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_? The unset after negotiation I proposed turned out it won't work: the feature is already negotiated; unsetting it only in vhost side doesn't change anything. Besides, it may break the migration as Michael stated below. > Therein lies a problem. If dpdk tweaks flags, updating it > will break guest migration. > > One way is to require that users specify all flags fully when > creating the virtio net device. Like how? By a new command line option? And user has to type all those features? > QEMU could verify that all required > flags are set, and fail init if not. > > This has other advantages, e.g. it adds ability to > init device without waiting for dpdk to connect. > > However, enabling each new feature would now require > management work. How about dpdk ships the list > of supported features instead? > Management tools could read them on source and destination > and select features supported on both sides. That means the management tool would somehow has a dependency on DPDK project, which I have no objection at all. But, is that a good idea? BTW, I'm not quite sure I followed your idea. I mean, how it supposed to fix the ANY_LAYOUT issue here? How this flag will be set for legacy device? --yliu