Re: [Qemu-devel] [PATCH v7 35/42] Don't sync dirty bitmaps in postcopy

[Amit Shah]

On (Fri) 31 Jul 2015 [10:50:46], Dr. David Alan Gilbert wrote:
> * Amit Shah (address@hidden) wrote:
> > On (Tue) 16 Jun 2015 [11:26:48], Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > > 
> > > Once we're in postcopy the source processors are stopped and memory
> > > shouldn't change any more, so there's no need to look at the dirty
> > > map.
> > > 
> > > There are two notes to this:
> > >   1) If we do resync and a page had changed then the page would get
> > >      sent again, which the destination wouldn't allow (since it might
> > >      have also modified the page)
> > >   2) Before disabling this I'd seen very rare cases where a page had been
> > >      marked dirtied although the memory contents are apparently identical
> > 
> > I suppose we don't know why.  Any way to send a message to the dest
> > with this info, so the dest can print out something?  That'll help in
> > debugging.  (I'm suggesting sending a message to the dest, because
> > after a migration, we don't ever think of looking at messages on the
> > src.  And chances are the dest could blow up after a migration is
> > successful because of such "corruption".)
> 
> One way perhaps would be to do one more sync at the end, after migration
> is apparently finished, but before the socket was closed; that would
> detect these changes and you could send a message to the other end.  However,
> given that (2) I say that where I'd seen it the page contents were
> identical, this could be a false alarm, so we'd need to be careful.
> It also doesn't help you find out *why* it happens, since tracing
> back from a bit in the migration bitmap to the area of memory
> and the thing that marked it dirty is very hard.  The only way to do
> that, is to mark the memory as read-only and then get a backtrace
> to find out who tried to change it; but you don't want to do
> that on a normal build and cause the source to die.

Agreed - but some notification that something might possibly be wrong
is better than we not having such a clue, and fervently trying to
debug an issue.  In fact, a per-VM flag could be better since multiple
migrations may mean such notifications could be lost in the logs of a
previous host which we don't examine.

                Amit