Re: [Qemu-devel] [PATCH 1/1] spapr: Do not re-read the clock on pre_save handler on migration

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]

On Mon, May 20, 2019 at 05:43:40PM -0300, Maxiwell S. Garcia wrote:
> This handler was added in the commit:
>   42043e4f1241: spapr: clock should count only if vm is running
> 
> In a scenario without migration, this pre_save handler is not
> triggered, so the 'stop/cont' commands save and restore the clock
> in the function 'cpu_ppc_clock_vm_state_change.' The SW clock
> in the guest doesn't know about this pause.
> 
> If the command 'migrate' is called between 'stop' and 'cont',
> the pre_save handler re-read the clock, and the SW clock in the
> guest will know about the pause between 'stop' and 'migrate.'
> If the guest is running a workload like HTC, a side-effect of
> this is a lot of process stall messages (with call traces) in
> the kernel guest.
> 
> Signed-off-by: Maxiwell S. Garcia <maxiwell@linux.ibm.com>

What affect will this have on the clock for the case of migrations
without a stop/cont around?  The complicated thing here is that for
*explicit* stops/continues we want to freeze the clock, however for
the implicit stop/continue during migration downtime, we want to keep
the clock running (logically), so that the guest time of day doesn't
get out of sync on migration.

> ---
>  hw/ppc/ppc.c | 24 ------------------------
>  1 file changed, 24 deletions(-)
> 
> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
> index ad20584f26..3fb50cbeee 100644
> --- a/hw/ppc/ppc.c
> +++ b/hw/ppc/ppc.c
> @@ -1056,35 +1056,11 @@ void cpu_ppc_clock_vm_state_change(void *opaque, int running,
>      }
>  }
>  
> -/*
> - * When migrating, read the clock just before migration,
> - * so that the guest clock counts during the events
> - * between:
> - *
> - *  * vm_stop()
> - *  *
> - *  * pre_save()
> - *
> - *  This reduces clock difference on migration from 5s
> - *  to 0.1s (when max_downtime == 5s), because sending the
> - *  final pages of memory (which happens between vm_stop()
> - *  and pre_save()) takes max_downtime.

Urgh.. this comment is confusing - 5s would be a ludicrously long
max_downtime by modern standards.

> - */
> -static int timebase_pre_save(void *opaque)
> -{
> -    PPCTimebase *tb = opaque;
> -
> -    timebase_save(tb);
> -
> -    return 0;
> -}
> -
>  const VMStateDescription vmstate_ppc_timebase = {
>      .name = "timebase",
>      .version_id = 1,
>      .minimum_version_id = 1,
>      .minimum_version_id_old = 1,
> -    .pre_save = timebase_pre_save,
>      .fields      = (VMStateField []) {
>          VMSTATE_UINT64(guest_timebase, PPCTimebase),
>          VMSTATE_INT64(time_of_the_day_ns, PPCTimebase),

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]