Re: [Xen-devel] [Patch v2] tools/migrate: Fix regression when migrating from older version of Xen

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-07-18 at 14:01 +0100, Andrew Cooper wrote:
> On 16/07/13 11:52, Andrew Cooper wrote:
> > Commit 00a4b65f8534c9e6521eab2e6ce796ae36037774 Sep 7 2010
> >   "libxc: provide notification of final checkpoint to restore end"
> > broke migration from any version of Xen using tools from prior to that 
> > commit
> >
> > Older tools have no idea about an XC_SAVE_ID_LAST_CHECKPOINT, causing newer
> > tools xc_domain_restore() to start reading the qemu save record, as
> > ctx->last_checkpoint is 0.
> >
> > The failure looks like:
> >   xc: error: Max batch size exceeded (1970103633). Giving up.
> > where 1970103633 = 0x756d6551 = *(uint32_t*)"Qemu"
> >
> > Sadly, the simple fix of just setting ctx->last_checkpoint = 1 will cause an
> > opposite function regresson for anyone using the current behaviour of
> > save_callbacks->checkpoint().
> >
> > The only safe fix is to rely on the toolstack to provide this information.
> >
> > Passing 0 results in unchanged behaviour, while passing nonzero means "the
> > other end of the migration stream does not know about
> > XC_SAVE_ID_LAST_CHECKPOINT but is performing a normal migrate"

Can we just say "the other end is performing a normal migrate"? That's
what I was originally trying to suggest, I think it is as you have
implemented it anyway.

> > diff --git a/tools/libxl/libxl_save_helper.c 
> > b/tools/libxl/libxl_save_helper.c
> > index 772251a..8f14b8b 100644
> > --- a/tools/libxl/libxl_save_helper.c
> > +++ b/tools/libxl/libxl_save_helper.c
> > @@ -264,7 +264,7 @@ int main(int argc, char **argv)
> >          r = xc_domain_restore(xch, io_fd, dom, store_evtchn, &store_mfn,
> >                                store_domid, console_evtchn, &console_mfn,
> >                                console_domid, hvm, pae, superpages,
> > -                              no_incr_genidad, &genidad,
> > +                              no_incr_genidad, 0, &genidad,

Does the "xl remus" or "xl save -c" stuff not result in a call chain
which ends up here wanting to pass 1?

> >                                &helper_restore_callbacks);
> >          helper_stub_restore_results(store_mfn,console_mfn,genidad,0);
> >          complete(r);
> > diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> > index 35d725c..e657c7f 100644
> > --- a/tools/xcutils/xc_restore.c
> > +++ b/tools/xcutils/xc_restore.c
> > @@ -52,7 +52,7 @@ main(int argc, char **argv)
> >  
> >      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
> >                              console_evtchn, &console_mfn, 0, hvm, pae, 
> > superpages,
> > -                            0, NULL, NULL);
> > +                            0, 0, NULL, NULL);
> >  
> >      if ( ret == 0 )
> >      {
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel