[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 24/47] Allow savevm handlers to state whether
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH v4 24/47] Allow savevm handlers to state whether they could go into postcopy |
Date: |
Fri, 21 Nov 2014 17:58:06 +1100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Wed, Nov 19, 2014 at 05:53:54PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (address@hidden) wrote:
> > On Fri, Oct 03, 2014 at 06:47:30PM +0100, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > >
> > > Use that to split the qemu_savevm_state_pending counts into postcopiable
> > > and non-postcopiable amounts
> > >
> > > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > > ---
> > > 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.
--
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
pgpnOS04iygwk.pgp
Description: PGP signature