On 26/07/2018 07:07, David Gibson wrote: > On Thu, May 03, 2018 at 11:20:44PM -0500, Michael Roth wrote: >> In some cases (e.g. spapr) we record guest timebase after qmp_stop() >> via a runstate hook so we can restore it on qmp_cont(). If a migration >> occurs in between those events we end up saving it again, this time >> based on the current timebase the guest would be seeing had it been >> running. This has the effect of advancing the guest timebase while >> it is stopped, which is not what the code intends. >> >> Other than simple jumps in time, this has been seen to trigger what >> appear to be RCU-related crashes in recent kernels when the advance >> exceeds rcu_cpu_stall_timeout, and it can be triggered by fairly >> common operations such as `virsh migrate ... --timeout 60`. >> >> Cc: Alexey Kardashevskiy <a...@ozlabs.ru> >> Cc: David Gibson <da...@gibson.dropbear.id.au> >> Cc: Laurent Vivier <lviv...@redhat.com> >> Cc: qemu-...@nongnu.org >> Cc: qemu-sta...@nongnu.org >> Signed-off-by: Michael Roth <mdr...@linux.vnet.ibm.com> > > Sorry, this fell off my radar for ages, but I've finally had a chance > to look at it properly. > > I'm not totally convinced this handle all the possible edge cases > correctly, but I am convinced it gives behaviour that's more correct > than we have now. It doesn't introduce changes to the interface or > migration stream that would break things in future, so I've applied it > to ppc-for-3.1.
See https://bugzilla.redhat.com/show_bug.cgi?id=1571230#c8 So you revert: commit 42043e4f1241eeb77f87f5816b5cf0b6e9583ed7 Author: Laurent Vivier <lviv...@redhat.com> Date: Fri Jan 27 13:24:58 2017 +0100 spapr: clock should count only if vm is running and change the behaviour compared to x86_64 6053a86 kvmclock: reduce kvmclock difference on migration Is this what you want? Thanks, Laurent
