On Fri, Oct 03, 2014 at 06:47:30PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <dgilb...@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 <dgilb...@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.
--
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
pgp0vkHdSPXi7.pgp
Description: PGP signature
