linux-kernel - Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56680E33.6040204@intel.com>
Date:	Wed, 9 Dec 2015 19:19:15 +0800
From:	"Lan, Tianyu" <tianyu.lan@...el.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	"Dong, Eddie" <eddie.dong@...el.com>,
	"a.motakis@...tualopensystems.com" <a.motakis@...tualopensystems.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	"b.reynal@...tualopensystems.com" <b.reynal@...tualopensystems.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"Jani, Nrupal" <nrupal.jani@...el.com>,
	Alexander Graf <agraf@...e.de>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
	"Tantilov, Emil S" <emil.s.tantilov@...el.com>,
	Or Gerlitz <gerlitz.or@...il.com>,
	"Rustad, Mark D" <mark.d.rustad@...el.com>,
	Eric Auger <eric.auger@...aro.org>,
	intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Williams, Mitch A" <mitch.a.williams@...el.com>,
	Netdev <netdev@...r.kernel.org>,
	"Nelson, Shannon" <shannon.nelson@...el.com>,
	Wei Yang <weiyang@...ux.vnet.ibm.com>,
	"zajec5@...il.com" <zajec5@...il.com>
Subject: Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for
 SRIOV NIC

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/