On Thu, Mar 24, 2016 at 02:50:56PM +0000, Li, Liang Z wrote:
> > > > > >> Given the typical speed of networks; it wouldn't do too much
> > > > > >> harm to start sending assuming all pages are dirty and then
> > > > > >> when the guest finally gets around to finishing the bitmap then
> > > > > >> update, so it's asynchronous - and then if the guest never
> > > > > >> responds we don't really
> > > > care.
> > > > > >
> > > > > >Indeed, thanks!
> > > > > >
> > > > >
> > > > > This is interesting. By doing so, the threshold I mentioned in
> > > > > another mail is not necessary, since we can do it in parallel.
> > > >
> > > > Actually I just realised it's a little more complex; we can't sync
> > > > the dirty bitmap again from the guest until after we've received the
> > guests 'free'
> > > > bitmap; that's because we wouldn't know if a 'dirty' page reflected
> > > > that a page declared as 'free' had now been reused - so there is
> > > > still an ordering there.
> > > >
> > > > Dave
> > >
> > > Not very complex, we can implement like this:
> > >
> > > 1. Set all the bits in the migration_bitmap_rcu->bmap to 1 2. Clear
> > > all the bits in ram_list. dirty_memory[DIRTY_MEMORY_MIGRATION]
> > > 3. Send the get_free_page_bitmap request 4. Start to send pages to
> > > destination and check if the free_page_bitmap is ready
> > > if (is_ready) {
> > > filter out the free pages from migration_bitmap_rcu->bmap;
> > > migration_bitmap_sync();
> > > }
> > > continue until live migration complete.
> > >
> > >
> > > Is that right?
> >
> > The order I'm trying to understand is something like:
> >
> > a) Send the get_free_page_bitmap request
> > b) Start sending pages
> > c) Reach the end of memory
> > [ is_ready is false - guest hasn't made free map yet ]
> > d) normal migration_bitmap_sync() at end of first pass
> > e) Carry on sending dirty pages
> > f) is_ready is true
> > f.1) filter out free pages?
> > f.2) migration_bitmap_sync()
> >
> > It's f.1 I'm worried about. If the guest started generating the free bitmap
> > before (d), then a page marked as 'free' in f.1 might have become dirty
> > before (d) and so (f.2) doesn't set the dirty again, and so we can't filter out
> > pages in f.1.
> >
>
> As you described, the order is incorrect.
>
> Liang
So to make it safe, what is required is to make
sure no free list us outstanding before calling
migration_bitmap_sync.
If one is outstanding, filter out pages before
calling migration_bitmap_sync.
Of course, if we just do it like we normally
do with migration, then by the time we call
migration_bitmap_sync dirty bitmap
is completely empty, so there won't be
anything to filter out.
One way to address this is call migration_bitmap_sync
in the IO handler, while VCPU is stopped,
then make sure to filter out pages before the next
migration_bitmap_sync.
Another is to start filtering out pages upon
IO handler, but make sure to flush the queue
before calling migration_bitmap_sync.
> > Dave
> >
> > >
> > > Liang
> > > >
> > > > >
> > > > > >Liang
> > --
> > Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
