Xen devel - Jun 2013 - [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases

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 in v6:

Fix hrtimers_resume() to handle resuming with two or more online CPUs
instead of adding a hrtimers_late_resume().  Add a flag to the
pvclock_gtod notififcations for the clock being set and go back to
using this to sync the Xen wallclock.

Changes in v5:

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.

Changes in v4:

Add a new clock_was_set notifier chain. Use this instead of direct
calls to clock_was_set() from the timekeeping code.  Use this notifier
and a new timer to synchronize the Xen wallclock.

Changes in v3:

Don''t peek at the timekeeper internals (use __current_kernel_time()
instead).  Use the native set_wallclock hook in dom0.

Changes in v2:

Reworked to use the pvclock_gtod notifier to sync the wallclock (this
looked similar to what a KVM host does).  update_persistent_clock()
will now only update the CMOS RTC.

David

On Thu, 27 Jun 2013, David Vrabel wrote:
> These series fixes the above limitations and depends on "x86: increase
> precision of x86_platform.get/set_wallclock()" which was previously
> posted.
So I''d like to merge that in the following way:

I pick up patches 1-3 and stick them into tip timers/for-xen and merge
that branch into timers/core. When picking up 1/6, I''ll drop the xen
part of that, so timers/core will not hold any xen specific bits.

Then the xen folks can pull timers/for-xen and apply the xen specific
stuff on top.

Thanks,

	tglx

On Fri, Jun 28, 2013 at 03:14:42PM +0200, Thomas Gleixner
wrote:
> On Thu, 27 Jun 2013, David Vrabel wrote:
> > These series fixes the above limitations and depends on "x86:
increase
> > precision of x86_platform.get/set_wallclock()" which was
previously
> > posted.
> 
> So I''d like to merge that in the following way:
> 
> I pick up patches 1-3 and stick them into tip timers/for-xen and merge
> that branch into timers/core. When picking up 1/6, I''ll drop the
xen
> part of that, so timers/core will not hold any xen specific bits.
> 
> Then the xen folks can pull timers/for-xen and apply the xen specific
> stuff on top.
Wouldn''t it be easier for you to pick the "xen part of that"
as well?
I am OK with you doing that and it all going through your tree.

But if it is easier for you to do the way you said - I can do that too.
Just tell me when to pull timers/for-xen
> 
> Thanks,
> 
> 	tglx
> 
>

On Fri, 28 Jun 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 28, 2013 at 03:14:42PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 Jun 2013, David Vrabel wrote:
> > > These series fixes the above limitations and depends on
"x86: increase
> > > precision of x86_platform.get/set_wallclock()" which was
previously
> > > posted.
> > 
> > So I''d like to merge that in the following way:
> > 
> > I pick up patches 1-3 and stick them into tip timers/for-xen and merge
> > that branch into timers/core. When picking up 1/6, I''ll drop
the xen
> > part of that, so timers/core will not hold any xen specific bits.
> > 
> > Then the xen folks can pull timers/for-xen and apply the xen specific
> > stuff on top.
> 
> Wouldn''t it be easier for you to pick the "xen part of
that" as well?
> I am OK with you doing that and it all going through your tree.
I can do that, if that''s not conflicting with other xen/x86 stuff
outside of timers/core.

Thanks,

	tglx

On Fri, Jun 28, 2013 at 05:12:35PM +0200, Thomas Gleixner
wrote:
> On Fri, 28 Jun 2013, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jun 28, 2013 at 03:14:42PM +0200, Thomas Gleixner wrote:
> > > On Thu, 27 Jun 2013, David Vrabel wrote:
> > > > These series fixes the above limitations and depends on
"x86: increase
> > > > precision of x86_platform.get/set_wallclock()" which
was previously
> > > > posted.
> > > 
> > > So I''d like to merge that in the following way:
> > > 
> > > I pick up patches 1-3 and stick them into tip timers/for-xen and
merge
> > > that branch into timers/core. When picking up 1/6, I''ll
drop the xen
> > > part of that, so timers/core will not hold any xen specific bits.
> > > 
> > > Then the xen folks can pull timers/for-xen and apply the xen
specific
> > > stuff on top.
> > 
> > Wouldn''t it be easier for you to pick the "xen part of
that" as well?
> > I am OK with you doing that and it all going through your tree.
> 
> I can do that, if that''s not conflicting with other xen/x86 stuff
> outside of timers/core.
I got one change in there and it seems to apply cleanly (woot!).
But lets be on a safe side. There are also some Xen ARM changes that
are fiddling with arch/x86/xen/time.c (different maintainer)) - so both
me and Stefano can pull from the timers/for-xen and not have to worry about
conflict resolution.

Thanks!
> 
> Thanks,
> 
> 	tglx
>

On Fri, 28 Jun 2013, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 28, 2013 at 05:12:35PM +0200, Thomas Gleixner wrote:
> > On Fri, 28 Jun 2013, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Jun 28, 2013 at 03:14:42PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 27 Jun 2013, David Vrabel wrote:
> > > > > These series fixes the above limitations and depends on
"x86: increase
> > > > > precision of x86_platform.get/set_wallclock()"
which was previously
> > > > > posted.
> > > > 
> > > > So I''d like to merge that in the following way:
> > > > 
> > > > I pick up patches 1-3 and stick them into tip timers/for-xen
and merge
> > > > that branch into timers/core. When picking up 1/6,
I''ll drop the xen
> > > > part of that, so timers/core will not hold any xen specific
bits.
> > > > 
> > > > Then the xen folks can pull timers/for-xen and apply the xen
specific
> > > > stuff on top.
> > > 
> > > Wouldn''t it be easier for you to pick the "xen part
of that" as well?
> > > I am OK with you doing that and it all going through your tree.
> > 
> > I can do that, if that''s not conflicting with other xen/x86
stuff
> > outside of timers/core.
> 
> I got one change in there and it seems to apply cleanly (woot!).
> But lets be on a safe side. There are also some Xen ARM changes that
> are fiddling with arch/x86/xen/time.c (different maintainer)) - so both
> me and Stefano can pull from the timers/for-xen and not have to worry about
> conflict resolution.
Hrmpf, just noticed, that it depends on other stuff in timers/core:

ce0b098: x86: Fix vrtc_get_time/set_mmss to use new timespec interface
3565184: x86: Increase precision of x86_platform.get/set_wallclock()

/me rumages for frozen shark.