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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
