From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 5/5] x86/xen: sync the CMOS RTC as well as the Xen wallclock Date: Fri, 28 Jun 2013 16:49:53 +0100 Message-ID: <51CDB0A1.6080409__14842.8735243671$1372434704$gmane$org@citrix.com> References: <1372329348-20841-1-git-send-email-david.vrabel@citrix.com> <1372329348-20841-6-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Thomas Gleixner Cc: John Stultz , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 28/06/13 16:38, Thomas Gleixner wrote: > On Thu, 27 Jun 2013, David Vrabel wrote: > >> From: David Vrabel >> >> Adjustments to Xen's persistent clock via update_persistent_clock() >> don't actually persist, as the Xen wallclock is a software only clock >> and modifications to it do not modify the underlying CMOS RTC. >> >> The x86_platform.set_wallclock hook can be used to keep the hardware >> RTC synchronized (as on bare metal). Because the Xen wallclock is now >> kept synchronized by pvclock_gtod notifier, xen_set_wallclock() need >> not do this and dom0 can simply use the native implementation. > > I can understand that part, but ... > >> static int xen_pvclock_gtod_notify(struct notifier_block *nb, unsigned long was_set, >> void *priv) >> { >> + static struct timespec next; >> struct timespec now; >> struct xen_platform_op op; >> >> - if (!was_set) >> - return NOTIFY_OK; >> - >> now = __current_kernel_time(); >> >> + if (!was_set && timespec_compare(&now, &next) < 0) >> + return NOTIFY_OK; >> + >> op.cmd = XENPF_settime; >> op.u.settime.secs = now.tv_sec; >> op.u.settime.nsecs = now.tv_nsec; >> op.u.settime.system_time = xen_clocksource_read(); >> >> (void)HYPERVISOR_dom0_op(&op); >> + >> + /* >> + * Don't update the wallclock for another 11 minutes. This is >> + * the same period as the sync_cmos_clock() work. >> + */ >> + next = now; >> + next.tv_sec += 11*60; >> + > > How is this related to the changelog? /me is confused ..... Before: Xen wallclock set when time is stepped. Xen wallclock set every 11 minutes (by sync_cmos_clock()). Hardware RTC never set. After: Xen wallclock set when time is stepped. Xen wallclock set every 11 minutes (in pvclock gtod notifier). Hardware RTC set every 11 minutes (by sync_cmos_clock()). I'll update the changelog to be more descriptive: Adjustments to Xen's persistent clock via update_persistent_clock() don't actually persist, as the Xen wallclock is a software only clock and modifications to it do not modify the underlying CMOS RTC. The x86_platform.set_wallclock hook can be used to keep the hardware RTC synchronized (as on bare metal). If (in dom0) we make the Xen wallclock periodically synchronized by the pvclock_gtod notifier, the set_wallclock hook need not update the Xen wallclock and the native implementation can be used. Is that better? David