From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753295AbbKYQWX (ORCPT ); Wed, 25 Nov 2015 11:22:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44401 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752034AbbKYQWU (ORCPT ); Wed, 25 Nov 2015 11:22:20 -0500 Date: Wed, 25 Nov 2015 18:22:10 +0200 From: "Michael S. Tsirkin" To: "Lan, Tianyu" Cc: a.motakis@virtualopensystems.com, alex.williamson@redhat.com, b.reynal@virtualopensystems.com, bhelgaas@google.com, carolyn.wyborny@intel.com, donald.c.skidmore@intel.com, eddie.dong@intel.com, nrupal.jani@intel.com, agraf@suse.de, kvm@vger.kernel.org, pbonzini@redhat.com, qemu-devel@nongnu.org, emil.s.tantilov@intel.com, gerlitz.or@gmail.com, mark.d.rustad@intel.com, eric.auger@linaro.org, intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com, jesse.brandeburg@intel.com, john.ronciak@intel.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, matthew.vick@intel.com, mitch.a.williams@intel.com, netdev@vger.kernel.org, shannon.nelson@intel.com, weiyang@linux.vnet.ibm.com, zajec5@gmail.com Subject: Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Message-ID: <20151125181618-mutt-send-email-mst@redhat.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> <20151125142437-mutt-send-email-mst@redhat.com> <5655DB99.3040007@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5655DB99.3040007@intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 26, 2015 at 12:02:33AM +0800, Lan, Tianyu wrote: > On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: > >Frankly, I don't really see what this short term hack buys us, > >and if it goes in, we'll have to maintain it forever. > > > > The framework of how to notify VF about migration status won't be > changed regardless of stopping VF or not before doing migration. > We hope to reach agreement on this first. Well it's bi-directional, the framework won't work if it's uni-directional. Further, if you use this interface to stop the interface at the moment, you won't be able to do anything else with it, and will need a new one down the road. > Tracking dirty memory still > need to more discussions and we will continue working on it. Stop VF may > help to work around the issue and make tracking easier. > > > >Also, assuming you just want to do ifdown/ifup for some reason, it's > >easy enough to do using a guest agent, in a completely generic way. > > > > Just ifdown/ifup is not enough for migration. It needs to restore some PCI > settings before doing ifup on the target machine I'd focus on just restoring then. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cpu-0002uj-5C for qemu-devel@nongnu.org; Wed, 25 Nov 2015 11:22:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1cpp-0007Oi-9M for qemu-devel@nongnu.org; Wed, 25 Nov 2015 11:22:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cpp-0007OC-3l for qemu-devel@nongnu.org; Wed, 25 Nov 2015 11:22:21 -0500 Date: Wed, 25 Nov 2015 18:22:10 +0200 From: "Michael S. Tsirkin" Message-ID: <20151125181618-mutt-send-email-mst@redhat.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> <20151125142437-mutt-send-email-mst@redhat.com> <5655DB99.3040007@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5655DB99.3040007@intel.com> Subject: Re: [Qemu-devel] [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Lan, Tianyu" Cc: weiyang@linux.vnet.ibm.com, emil.s.tantilov@intel.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, jesse.brandeburg@intel.com, mark.d.rustad@intel.com, carolyn.wyborny@intel.com, eric.auger@linaro.org, donald.c.skidmore@intel.com, zajec5@gmail.com, agraf@suse.de, matthew.vick@intel.com, intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com, gerlitz.or@gmail.com, mitch.a.williams@intel.com, nrupal.jani@intel.com, bhelgaas@google.com, a.motakis@virtualopensystems.com, b.reynal@virtualopensystems.com, linux-api@vger.kernel.org, shannon.nelson@intel.com, eddie.dong@intel.com, alex.williamson@redhat.com, linux-kernel@vger.kernel.org, john.ronciak@intel.com, netdev@vger.kernel.org, pbonzini@redhat.com On Thu, Nov 26, 2015 at 12:02:33AM +0800, Lan, Tianyu wrote: > On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: > >Frankly, I don't really see what this short term hack buys us, > >and if it goes in, we'll have to maintain it forever. > > > > The framework of how to notify VF about migration status won't be > changed regardless of stopping VF or not before doing migration. > We hope to reach agreement on this first. Well it's bi-directional, the framework won't work if it's uni-directional. Further, if you use this interface to stop the interface at the moment, you won't be able to do anything else with it, and will need a new one down the road. > Tracking dirty memory still > need to more discussions and we will continue working on it. Stop VF may > help to work around the issue and make tracking easier. > > > >Also, assuming you just want to do ifdown/ifup for some reason, it's > >easy enough to do using a guest agent, in a completely generic way. > > > > Just ifdown/ifup is not enough for migration. It needs to restore some PCI > settings before doing ifup on the target machine I'd focus on just restoring then. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael S. Tsirkin Date: Wed, 25 Nov 2015 18:22:10 +0200 Subject: [Intel-wired-lan] [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver In-Reply-To: <5655DB99.3040007@intel.com> References: <1448372298-28386-1-git-send-email-tianyu.lan@intel.com> <1448372298-28386-4-git-send-email-tianyu.lan@intel.com> <20151124230551-mutt-send-email-mst@redhat.com> <56554994.1090305@intel.com> <20151125142437-mutt-send-email-mst@redhat.com> <5655DB99.3040007@intel.com> Message-ID: <20151125181618-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Thu, Nov 26, 2015 at 12:02:33AM +0800, Lan, Tianyu wrote: > On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: > >Frankly, I don't really see what this short term hack buys us, > >and if it goes in, we'll have to maintain it forever. > > > > The framework of how to notify VF about migration status won't be > changed regardless of stopping VF or not before doing migration. > We hope to reach agreement on this first. Well it's bi-directional, the framework won't work if it's uni-directional. Further, if you use this interface to stop the interface at the moment, you won't be able to do anything else with it, and will need a new one down the road. > Tracking dirty memory still > need to more discussions and we will continue working on it. Stop VF may > help to work around the issue and make tracking easier. > > > >Also, assuming you just want to do ifdown/ifup for some reason, it's > >easy enough to do using a guest agent, in a completely generic way. > > > > Just ifdown/ifup is not enough for migration. It needs to restore some PCI > settings before doing ifup on the target machine I'd focus on just restoring then. -- MST