Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753746AbbLILTZ (ORCPT ); Wed, 9 Dec 2015 06:19:25 -0500 Received: from mga09.intel.com ([134.134.136.24]:35995 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410AbbLILTW (ORCPT ); Wed, 9 Dec 2015 06:19:22 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,403,1444719600"; d="scan'208";a="703499742" Subject: Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC To: "Michael S. Tsirkin" References: <565BF285.4040507@intel.com> <565DB6FF.1050602@intel.com> <20151201171140-mutt-send-email-mst@redhat.com> <20151201193026-mutt-send-email-mst@redhat.com> <20151202105955-mutt-send-email-mst@redhat.com> <5661C000.8070201@intel.com> <20151209122831-mutt-send-email-mst@redhat.com> Cc: Alexander Duyck , "Dong, Eddie" , "a.motakis@virtualopensystems.com" , Alex Williamson , "b.reynal@virtualopensystems.com" , Bjorn Helgaas , "Wyborny, Carolyn" , "Skidmore, Donald C" , "Jani, Nrupal" , Alexander Graf , "kvm@vger.kernel.org" , Paolo Bonzini , "qemu-devel@nongnu.org" , "Tantilov, Emil S" , Or Gerlitz , "Rustad, Mark D" , Eric Auger , intel-wired-lan , "Kirsher, Jeffrey T" , "Brandeburg, Jesse" , "Ronciak, John" , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Williams, Mitch A" , Netdev , "Nelson, Shannon" , Wei Yang , "zajec5@gmail.com" From: "Lan, Tianyu" Message-ID: <56680E33.6040204@intel.com> Date: Wed, 9 Dec 2015 19:19:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151209122831-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2362 Lines: 58 On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote: > On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: >> Hi Michael & Alexander: >> Thanks a lot for your comments and suggestions. > > It's nice that it's appreciated, but you then go on and ignore > all that I have written here: > https://www.mail-archive.com/kvm@vger.kernel.org/msg123826.html > No, I will reply it separately and according your suggestion to snip it into 3 thread. >> We still need to support Windows guest for migration and this is why our >> patches keep all changes in the driver since it's impossible to change >> Windows kernel. > > This is not a reasonable argument. It makes no sense to duplicate code > on Linux because you must duplicate code on Windows. Let's assume you > must do it in the driver on windows because windows has closed source > drivers. What does it matter? Linux can still do it as part of DMA API > and have it apply to all drivers. > Sure. Duplicated code should be encapsulated and make it able to reuse by other drivers. Just like you said the dummy write part. I meant the framework should not require to change Windows kernel code (such as PM core or PCI bus driver)and this will block implementation on the Windows. I think it's not problem to duplicate code in the Windows drivers. >> Following is my idea to do DMA tracking. >> >> Inject event to VF driver after memory iterate stage >> and before stop VCPU and then VF driver marks dirty all >> using DMA memory. The new allocated pages also need to >> be marked dirty before stopping VCPU. All dirty memory >> in this time slot will be migrated until stop-and-copy >> stage. We also need to make sure to disable VF via clearing the >> bus master enable bit for VF before migrating these memory. >> >> The dma page allocated by VF driver also needs to reserve space >> to do dummy write. > > I suggested ways to do it all in the hypervisor without driver hacks, or > hide it within DMA API without need to reserve extra space. Both > approaches seem much cleaner. > This sounds reasonable. We may discuss it detail in the separate thread. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/