Messages in this thread | | | Subject | Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC | From | "Lan, Tianyu" <> | Date | Wed, 9 Dec 2015 19:19:15 +0800 |
| |
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.
| |