From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1T2M-0005oQ-Me for qemu-devel@nongnu.org; Wed, 25 Nov 2015 00:54:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1T2J-00034s-Gy for qemu-devel@nongnu.org; Wed, 25 Nov 2015 00:54:38 -0500 Received: from mga02.intel.com ([134.134.136.20]:7843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1T2I-00034m-SU for qemu-devel@nongnu.org; Wed, 25 Nov 2015 00:54:35 -0500 Message-ID: <56554994.1090305@intel.com> Date: Wed, 25 Nov 2015 13:39:32 +0800 From: Lan Tianyu MIME-Version: 1.0 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> In-Reply-To: <20151124230551-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: "Michael S. Tsirkin" 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 2015年11月25日 05:20, Michael S. Tsirkin wrote: > I have to say, I was much more interested in the idea > of tracking dirty memory. I have some thoughts about > that one - did you give up on it then? No, our finial target is to keep VF active before doing migration and tracking dirty memory is essential. But this seems not easy to do that in short term for upstream. As starters, stop VF before migration. After deep thinking, the way of stopping VF still needs tracking DMA-accessed dirty memory to make sure the received data buffer before stopping VF migrated. It's easier to do that via dummy writing data buffer when receive packet. -- Best regards Tianyu Lan