Re: [Qemu-devel] [PATCH v4 24/47] Allow savevm handlers to state whether they could go into postcopy

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

* David Gibson (david@gibson.dropbear.id.au) wrote:
> On Wed, Nov 19, 2014 at 05:53:54PM +0000, Dr. David Alan Gilbert wrote:
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > On Fri, Oct 03, 2014 at 06:47:30PM +0100, Dr. David Alan Gilbert (git) wrote:
> > > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > > 
> > > > Use that to split the qemu_savevm_state_pending counts into postcopiable
> > > > and non-postcopiable amounts
> > > > 
> > > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > > ---
> > > >  arch_init.c                 |  7 +++++++
> > > >  include/migration/vmstate.h |  2 +-
> > > >  include/sysemu/sysemu.h     |  4 +++-
> > > >  migration.c                 |  9 ++++++++-
> > > >  savevm.c                    | 23 +++++++++++++++++++----
> > > >  5 files changed, 38 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/arch_init.c b/arch_init.c
> > > > index 6970733..44072d8 100644
> > > > --- a/arch_init.c
> > > > +++ b/arch_init.c
> > > > @@ -1192,6 +1192,12 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
> > > >      return ret;
> > > >  }
> > > >  
> > > > +/* RAM's always up for postcopying */
> > > > +static bool ram_can_postcopy(void *opaque)
> > > > +{
> > > > +    return true;
> > > > +}
> > > > +
> > > >  static SaveVMHandlers savevm_ram_handlers = {
> > > >      .save_live_setup = ram_save_setup,
> > > >      .save_live_iterate = ram_save_iterate,
> > > > @@ -1199,6 +1205,7 @@ static SaveVMHandlers savevm_ram_handlers = {
> > > >      .save_live_pending = ram_save_pending,
> > > >      .load_state = ram_load,
> > > >      .cancel = ram_migration_cancel,
> > > > +    .can_postcopy = ram_can_postcopy,
> > > 
> > > Is there actually any plausible device for which you'd need a callback
> > > here, rather than just having a static bool?
> > > 
> > > On the other hand, it does seem kind of plausible that there might be
> > > situations in which some data from a device must be pre-copied, but
> > > more can be post-copied, which would necessitate extending the
> > > per-handler callback to return quantities for both.
> > 
> > It's cheap enough and I couldn't make a strong argument about
> > any possible device, so I just used the function.
> 
> Ok.  I still wonder if it might be better to instead extend
> the save_live_pending callback in order to return both
> non-postcopyable and postcopyable quantites.  It allows for the case
> of a postcopyable device which has some non-postcopyable data - and
> with any postcopyable device other than RAM, it seems likely that
> there will need to be some precopied metadata at least.  Plus it
> avoids adding another callback.

There are two separate suggestions there - which I'll address in opposite order:
  1) Extending save_live_pending callback to avoid a new callback
    can_postcopy is used for a few diferent decisions; not just where
    to add the pending value to; so I don't think extending s_l_p saves
    the need for the other callback

  2) Allowing a device to do both pre and postcopy
    Yeh I can see you could theoretically have a device where that would be
    useful; but for reasonably small chunks of metadata it already gets
    the chance to send those during the _begin call.  I'll make the change
    to save_live_pending's parameters to let this work.

Dave

> 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson


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