Xen devel - May 2013 - [PATCH 1/2] x86/xen: sync the CMOS RTC as well as the Xen wallclock

From: David Vrabel <david.vrabel@citrix.com>

Adjustments to Xen''s persistent_clock via update_persistent_clock()
don''t actually persist, as the xen_set_walltime() just notifies other
domN guests that it has been updated, and does not modify the
underlying CMOS clock.

Thus, this patch modifies xen_set_wallclock() so it will set the
underlying CMOS clock when called from dom0, ensuring the
persistent_clock will be correct on the next hardware boot.

Dom0 does not support accessing EFI runtime services and Xen does not
run on Moorsetown platforms so the CMOS RTC is the only supported
hardware clock.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/time.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a1947ac..4656165 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -14,6 +14,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/math64.h>
 #include <linux/gfp.h>
+#include <linux/mc146818rtc.h>
 
 #include <asm/pvclock.h>
 #include <asm/xen/hypervisor.h>
@@ -199,17 +200,25 @@ static void xen_get_wallclock(struct timespec *now)
 static int xen_set_wallclock(const struct timespec *now)
 {
 	struct xen_platform_op op;
+	int ret;
 
 	/* do nothing for domU */
 	if (!xen_initial_domain())
 		return -1;
 
+	/* Set the Xen wallclock. */
 	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();
 
-	return HYPERVISOR_dom0_op(&op);
+	ret = HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/* Set the hardware RTC. */
+	return mach_set_rtc_mmss(now);
+
 }
 
 static struct clocksource xen_clocksource __read_mostly = {
-- 
1.7.2.5

On 05/28/2013 11:22 AM, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Adjustments to Xen''s persistent_clock via
update_persistent_clock()
> don''t actually persist, as the xen_set_walltime() just notifies
other
> domN guests that it has been updated, and does not modify the
> underlying CMOS clock.
>
> Thus, this patch modifies xen_set_wallclock() so it will set the
> underlying CMOS clock when called from dom0, ensuring the
> persistent_clock will be correct on the next hardware boot.
>
> Dom0 does not support accessing EFI runtime services and Xen does not
> run on Moorsetown platforms so the CMOS RTC is the only supported
> hardware clock.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Ok, I''ve queued this for 3.11.

thanks
-john

On Tue, May 28, 2013 at 12:01:57PM -0700, John Stultz
wrote:
> On 05/28/2013 11:22 AM, David Vrabel wrote:
> >From: David Vrabel <david.vrabel@citrix.com>
> >
> >Adjustments to Xen''s persistent_clock via
update_persistent_clock()
> >don''t actually persist, as the xen_set_walltime() just
notifies other
> >domN guests that it has been updated, and does not modify the
> >underlying CMOS clock.
> >
> >Thus, this patch modifies xen_set_wallclock() so it will set the
> >underlying CMOS clock when called from dom0, ensuring the
> >persistent_clock will be correct on the next hardware boot.
> >
> >Dom0 does not support accessing EFI runtime services and Xen does not
> >run on Moorsetown platforms so the CMOS RTC is the only supported
> >hardware clock.
> >
> >Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Ok, I''ve queued this for 3.11.
Thanks.
> 
> thanks
> -john
>