| commit | 711dfb2423a85fba91884b5a90a8c0712c152ce2 | |
| author | Greg Kurz <groug@kaod.org> | |
| Wed, 2 Dec 2020 17:28:26 +0000 (2 18:28 +0100) | ||
| committer | David Gibson <david@gibson.dropbear.id.au> | |
| Mon, 14 Dec 2020 04:54:12 +0000 (14 15:54 +1100) | ||
| tree | 9610f0f3699bbf9a822df5227ac265da0714bd37 | treesnapshot (tar.gz zip) |
| parent | f518be3aa35b0505eec36c36f4f8736906250681 | commitdiff |
hw/ppc: Do not re-read the clock on pre_save if doing savevm
A guest with enough RAM, eg. 128G, is likely to detect savevm downtime
and to complain about stalled CPUs. This happens because we re-read
the timebase just before migrating it and we thus don't account for
all the time between VM stop and pre-save.
A very similar situation was already addressed for live migration of
paused guests (commit d14f33976282). Extend the logic to do the same
with savevm.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1893787
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160693010619.1111945.632640981169395440.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A guest with enough RAM, eg. 128G, is likely to detect savevm downtime
and to complain about stalled CPUs. This happens because we re-read
the timebase just before migrating it and we thus don't account for
all the time between VM stop and pre-save.
A very similar situation was already addressed for live migration of
paused guests (commit d14f33976282). Extend the logic to do the same
with savevm.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1893787
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160693010619.1111945.632640981169395440.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| hw/ppc/ppc.c | diffblobblamehistory |