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 <maxiw...@linux.ibm.com>
---
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.
- */
-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),
--
2.20.1
