Re: [PATCHv5 0/4] xen: maintain an accurate persistent clock in morecases

From: Konrad Rzeszutek Wilk
Date: Fri Jun 21 2013 - 14:31:54 EST


On Thu, Jun 20, 2013 at 01:03:34PM -0700, John Stultz wrote:
> On 06/20/2013 12:16 PM, David Vrabel wrote:
> >Xen guests use the Xen wallclock as their persistent clock. This is a
> >software only clock in the hypervisor that is used by guests instead
> >of a real hardware RTC.
> >
> >The kernel has limited support for updating the persistent clock or
> >RTC when NTP is synced. This has the following limitations:
> >
> >* The persistent clock is not updated on step changes. This leaves a
> > window where it will be incorrect (while NTP resyncs).
> >
> >* Xen guests use the Xen wallclock as their persistent clock. dom0
> > maintains this clock so it is persistent for domUs but not dom0
> > itself.
> >
> >These limitations mean that guests started before NTP is synchronized
> >will start with an incorrect wallclock time and the hardware RTC will
> >not be updated (as on bare metal).
> >
> >These series fixes the above limitations and depends on "x86: increase
> >precision of x86_platform.get/set_wallclock()" which was previously
> >posted.
> >
> >Changes since v4:
> >
> >Dropped the change to disable non-boot CPUs during suspend on Xen as
> >migration downtime was too poor. Instead, provide
> >hrtimers_late_resume() for use by Xen's resume code to replace the
> >call of clock_was_set(). Fix two unused variable warnings.
>
> Ok, I've got these 4 in my pending stack. As long as Thomas doesn't
> object to the first two, and it doesn't run into any trouble in
> testing, I'll send them along for 3.12. (Acks from Xen maintainers
> would be nice for the last two as well).

Please consider them Acked-by.

Thanks!
>
> Thanks for all the effort through all the revisions here!
>
> thanks
> -john
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/