[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH] target/ppc: only save guest timebase once after stopping
Date: Thu, 26 Jul 2018 09:44:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]