Re: [Qemu-ppc] [PATCH] target/ppc: only save guest timebase once after stopping

[Laurent Vivier]

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 <address@hidden>
>> Cc: David Gibson <address@hidden>
>> Cc: Laurent Vivier <address@hidden>
>> Cc: address@hidden
>> Cc: address@hidden
>> Signed-off-by: Michael Roth <address@hidden>
> 
> 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 <address@hidden>
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