From: David Vrabel <david.vrabel@citrix.com>
To: John Stultz <john.stultz@linaro.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on system time step changes
Date: Tue, 14 May 2013 10:47:25 +0100 [thread overview]
Message-ID: <5192082D.4020400@citrix.com> (raw)
In-Reply-To: <5191880F.3030308@linaro.org>
On 14/05/13 01:40, John Stultz wrote:
> On 05/13/2013 10:56 AM, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> The persistent clock or the RTC is only synchronized with system time
>> every 11 minutes if NTP is running. This gives a window where the
>> persistent clock may be incorrect after a step change in the time
>> (such as on first boot).
>>
>> This particularly affects Xen guests as until an update to the control
>> domain's persistent clock, new guests will start with the incorrect
>> system time.
>>
>> When there is a step change in the system time, call
>> update_persistent_clock or rtc_set_ntp_time() to synchronize the
>> persistent clock or RTC to the new system time.
>
> I'm sorry, this isn't quite making sense to me. Could you further
> describe the exact problematic behavior you're seeing here, and why its
> a problem?
The Xen wallclock is used as the persistent clock for Xen guests. This
is initialized (by Xen) with the CMOS RTC at the start of day. If the
RTC is incorrect then guests will see an incorrect wallclock time until
dom0 has corrected it.
Currently dom0 only updates the Xen wallclock with the 11 min periodic
work when NTP is synced. This leaves a window where newly started
guests will see an incorrect wallclock time. This can cause guests to
fail to start correctly if the wallclock is now behind what it was when
the guest last started. (e.g., fsck of its disk fails as its last mount
time appears to be far into the future).
Similarly (but less problematic), if a bare metal system is rebooted
before the RTC is updated it will still have the incorrect time.
> You seem to be saying we should always set the RTC any time settimeofday
> is called (regardless of the NTP sync state), which doesn't seem right
> to me. Also I worry that this would cause the RTC to be set when the RTC
> hctosys() code (or hwclock) sets the time to the RTC clock, which is a
> bit circular.
I'm not too concerned about the behaviour of manual syncs of the RTC
because: a) if the kernel does this automatically then the use of manual
syncs is no longer necessary; and b) the RTC will still end up with the
correct time.
> I suspect once the problem is better understood, there will be a better
> solution then trying to always set the RTC on any settimeofday() call.
David
next prev parent reply other threads:[~2013-05-14 9:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 17:56 [PATCH 0/3] x86,time,xen: maintain an accurate persistent clock in more cases David Vrabel
2013-05-13 17:56 ` [PATCH 1/3] x86: increase precision of x86_platform.get/set_wallclock() David Vrabel
2013-05-14 0:57 ` John Stultz
2013-05-14 17:52 ` John Stultz
2013-05-29 0:18 ` John Stultz
2013-05-29 12:16 ` David Vrabel
2013-05-13 17:56 ` [PATCH 2/3] timekeeping: sync persistent clock and RTC on system time step changes David Vrabel
2013-05-14 0:40 ` John Stultz
2013-05-14 9:47 ` David Vrabel [this message]
2013-05-14 17:15 ` John Stultz
2013-05-15 8:16 ` [Xen-devel] " Jan Beulich
2013-05-15 18:10 ` John Stultz
2013-05-28 18:26 ` David Vrabel
2013-05-28 18:31 ` Konrad Rzeszutek Wilk
2013-05-28 19:09 ` John Stultz
2013-05-28 19:48 ` Konrad Rzeszutek Wilk
2013-05-28 20:03 ` John Stultz
2013-05-28 20:11 ` John Stultz
2013-05-28 20:25 ` Konrad Rzeszutek Wilk
2013-05-28 20:30 ` John Stultz
2013-05-28 19:06 ` John Stultz
2013-05-13 17:56 ` [PATCH 3/3] x86/xen: sync the CMOS RTC as well as the Xen wallclock David Vrabel
2013-05-14 0:52 ` John Stultz
2013-05-14 7:57 ` [Xen-devel] " Jan Beulich
2013-05-14 15:59 ` John Stultz
2013-05-14 16:14 ` Jan Beulich
2013-05-14 16:17 ` John Stultz
2013-05-14 16:24 ` Konrad Rzeszutek Wilk
2013-05-14 16:28 ` John Stultz
2013-05-14 9:55 ` David Vrabel
2013-05-14 17:24 ` John Stultz
2013-05-14 18:00 ` David Vrabel
2013-05-14 18:03 ` John Stultz
2013-05-15 8:19 ` [Xen-devel] " Jan Beulich
2013-05-15 18:13 ` John Stultz
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=5192082D.4020400@citrix.com \
--to=david.vrabel@citrix.com \
--cc=john.stultz@linaro.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).