[2/2] mc146818rtc: Reset the periodic timer on load

When loading a VM from a snapshot or migration, clock changes can cause
the periodic timer to stall or loop rapidly.

qemu-timer has a reset notifier mechanism that is used to avoid timer
stalls or loops if the host clock changes while the VM is running when
using QEMU_CLOCK_HOST.  However, when loading a snapshot or migration,
qemu-timer is initialized and fires the reset notifier before
mc146818rtc is initialized and has registered its reset handler.  In
addition, this mechanism isn't used when using QEMU_CLOCK_REALTIME,
which might also change when loading a snapshot or migration.

To correct that problem, this commit resets the periodic timer after
loading from a snapshot or migration if the clock has either jumped
backward or has jumped forward by more than the clock jump limit that
is used by the reset notifier code in qemu-timer.

Signed-off-by: Paul Donohue <qemu-git@PaulSD.com>
---
 hw/timer/mc146818rtc.c | 6 ++++++
 1 file changed, 6 insertions(+)

On 12/06/2015 16:10, Paul Donohue wrote:
> To correct that problem, this commit resets the periodic timer after
> loading from a snapshot or migration if the clock has either jumped
> backward or has jumped forward by more than the clock jump limit that
> is used by the reset notifier code in qemu-timer.
> 
> Signed-off-by: Paul Donohue <qemu-git@PaulSD.com>
> ---
>  hw/timer/mc146818rtc.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> index f2b77fa..68cf1f0 100644
> --- a/hw/timer/mc146818rtc.c
> +++ b/hw/timer/mc146818rtc.c
> @@ -723,6 +723,12 @@ static int rtc_post_load(void *opaque, int version_id)
>          check_update_timer(s);
>      }
>  
> +    uint64_t now = qemu_clock_get_ns(rtc_clock);
> +    if (now < (s->next_periodic_time - get_ticks_per_sec()) ||

What is the reason for the "- get_ticks_per_sec()" adjustment?  Can I
just remove it?

Paolo

> +        now > (s->next_periodic_time + get_max_clock_jump())) {

On Wed, Jun 17, 2015 at 04:01:33PM +0200, Paolo Bonzini wrote:
> On 12/06/2015 16:10, Paul Donohue wrote:
> > To correct that problem, this commit resets the periodic timer after
> > loading from a snapshot or migration if the clock has either jumped
> > backward or has jumped forward by more than the clock jump limit that
> > is used by the reset notifier code in qemu-timer.
> > 
> > diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> > @@ -723,6 +723,12 @@ static int rtc_post_load(void *opaque, int version_id)
> >          check_update_timer(s);
> >      }
> >  
> > +    uint64_t now = qemu_clock_get_ns(rtc_clock);
> > +    if (now < (s->next_periodic_time - get_ticks_per_sec()) ||
> 
> What is the reason for the "- get_ticks_per_sec()" adjustment?  Can I
> just remove it?

Short answer: Yes, you can remove it.

Long answer:
In the other (qemu-timer) patch, I thought it was a good idea to try to 
avoid calling the clock reset notifiers in cases where the clock 
"jumped" because the VM was idle, and err on the side of not calling 
the notifiers for real but small host clock changes.  At that layer of 
the abstraction, it is not clear how any particular RTC implementation 
might use the reset notification, so I didn't want to assume it was 
safe to trigger the notification too frequently.

That thought process carried over when I patched mc146818rtc.c, and I 
was trying to avoid calling periodic_timer_update() in any cases where 
it wasn't strictly needed.  At the time when a snapshot is taken, "now" 
should generally be less than "next_periodic_time" by up to one period 
worth of time.  In the case where the snapshot is loaded when "now" is 
still less than "next_periodic_time", "now < s->next_periodic_time" 
would not necessarily indicate that the clock has jumped backward.  
Calculating the period so we could evaluate 
"now < s->next_periodic_time - period" would involve duplicating a lot 
of the code from periodic_timer_update(), which I thought was a bad 
idea.  So, I simply assumed that the period would always be less than 1 
second, and used "- get_ticks_per_sec()" to err on the side of skipping 
the call to periodic_timer_update().

However, now that I'm looking at it again, calling
periodic_timer_update() when "now" is less than "next_periodic_time" by 
less than one period would have no effect anyway, so the 
"- get_ticks_per_sec()" adjustment is unnecessary, and it was silly for 
me to try to avoid a call to to periodic_timer_update() in that case.

Thanks!