Re: [Qemu-devel] [PULL 00/27] Migration pull

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote:
> > Hi
> > - rebase on top of lastest
> > - fix compilation on 32bit machines
> > - add Peter Xu cleanups
> >
> > Please, apply.
> >
> > The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93:
> >
> >   Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/juanquintela/qemu.git tags/migration/20180115
> >
> > for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f:
> >
> >   migration: remove notify in fd_error (2018-01-15 12:48:13 +0100)
> >
> > ----------------------------------------------------------------
> > migration/next for 20180115
> >
> > ----------------------------------------------------------------
> > Alexey Perevalov (6):
> >       migration: introduce postcopy-blocktime capability
> >       migration: add postcopy blocktime ctx into MigrationIncomingState
> >       migration: calculate vCPU blocktime on dst side
> >       migration: postcopy_blocktime documentation
> >       migration: add blocktime calculation into migration-test
> >       migration: add postcopy total blocktime into query-migrate
> 
> I suggest that we should for the moment revert
> 3be98be4e9f5  migration: calculate vCPU blocktime on dst side
> 5f32dc8ee073  migration: add blocktime calculation into migration-test
> ca6011c23291  migration: add postcopy total blocktime into query-migrate
> 
> unless there is an imminent fix for the ppc32 issues (which seems
> unlikely since the code is fundamentally assuming it can atomically
> do operations which can't be done atomically on all hosts).
> 
> I haven't yet tested that combination of reverts, I'm guessing
> at which subsequent commits depend on 3be98be4e9f5. Let me know
> if you have suggestions for additions/removals from the revert list.

It's probably better to remove the whole set of 6, then we can come
back to it later rather than leaving something half-implemented in
there.

Dave

> thanks
> -- PMM
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK