From: Paul Donohue <qemu-devel@PaulSD.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] mc146818rtc: Reset the periodic timer on load
Date: Thu, 18 Jun 2015 10:36:05 -0400 [thread overview]
Message-ID: <20150618143605.GB7886@TopQuark.net> (raw)
In-Reply-To: <55817DBD.1050502@redhat.com>
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!
prev parent reply other threads:[~2015-06-18 14:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 14:05 [Qemu-devel] [PATCH 0/2] qemu-timer/mc146818rtc: fix timer issues related to clock changes Paul Donohue
2015-06-12 14:08 ` [Qemu-devel] [PATCH 1/2] qemu-timer: Call clock reset notifiers on forward jumps Paul Donohue
2015-06-17 14:00 ` Paolo Bonzini
2015-06-18 12:58 ` Paul Donohue
2015-06-18 13:17 ` Paolo Bonzini
2015-06-12 14:10 ` [Qemu-devel] [PATCH 2/2] mc146818rtc: Reset the periodic timer on load Paul Donohue
2015-06-17 14:01 ` Paolo Bonzini
2015-06-18 14:36 ` Paul Donohue [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150618143605.GB7886@TopQuark.net \
--to=qemu-devel@paulsd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.