[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1306281805430.4013@ionos.tec.linutronix.de>
Date: Fri, 28 Jun 2013 18:09:15 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: David Vrabel <david.vrabel@...rix.com>
cc: xen-devel@...ts.xen.org,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH 5/5] x86/xen: sync the CMOS RTC as well as the Xen
wallclock
On Fri, 28 Jun 2013, David Vrabel wrote:
>
> 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).
Ah, you are emulating the sync_cmos_clock() behaviour for the xen
wallclock via the periodic pvclock_gtod notifier call.
> 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.
Yep. I'll pick that up.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists