* [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
@ 2013-06-27 10:35 David Vrabel
0 siblings, 0 replies; 12+ messages in thread
From: David Vrabel @ 2013-06-27 10:35 UTC (permalink / raw)
To: xen-devel
Cc: linux-kernel, Thomas Gleixner, John Stultz, David Vrabel,
Konrad Rzeszutek Wilk
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
@ 2013-06-27 10:35 David Vrabel
2013-06-28 13:14 ` Thomas Gleixner
2013-06-28 13:14 ` Thomas Gleixner
0 siblings, 2 replies; 12+ messages in thread
From: David Vrabel @ 2013-06-27 10:35 UTC (permalink / raw)
To: xen-devel
Cc: David Vrabel, Konrad Rzeszutek Wilk, linux-kernel, John Stultz,
Thomas Gleixner
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-27 10:35 David Vrabel
@ 2013-06-28 13:14 ` Thomas Gleixner
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 13:14 ` Thomas Gleixner
1 sibling, 2 replies; 12+ messages in thread
From: Thomas Gleixner @ 2013-06-28 13:14 UTC (permalink / raw)
To: David Vrabel; +Cc: xen-devel, Konrad Rzeszutek Wilk, LKML, John Stultz
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 13:14 ` Thomas Gleixner
@ 2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
1 sibling, 0 replies; 12+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-06-28 15:01 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, John Stultz, David Vrabel, xen-devel
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
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 13:14 ` Thomas Gleixner
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
@ 2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 15:12 ` Thomas Gleixner
2013-06-28 15:12 ` Thomas Gleixner
1 sibling, 2 replies; 12+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-06-28 15:01 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: David Vrabel, xen-devel, LKML, John Stultz
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
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
@ 2013-06-28 15:12 ` Thomas Gleixner
2013-06-28 15:12 ` Thomas Gleixner
1 sibling, 0 replies; 12+ messages in thread
From: Thomas Gleixner @ 2013-06-28 15:12 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: LKML, John Stultz, David Vrabel, xen-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 15:12 ` Thomas Gleixner
@ 2013-06-28 15:12 ` Thomas Gleixner
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
1 sibling, 2 replies; 12+ messages in thread
From: Thomas Gleixner @ 2013-06-28 15:12 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel, LKML, John Stultz
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 15:12 ` Thomas Gleixner
@ 2013-06-28 16:19 ` Konrad Rzeszutek Wilk
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
1 sibling, 0 replies; 12+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-06-28 16:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, John Stultz, David Vrabel, xen-devel
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 15:12 ` Thomas Gleixner
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
@ 2013-06-28 16:19 ` Konrad Rzeszutek Wilk
2013-06-28 18:58 ` Thomas Gleixner
1 sibling, 1 reply; 12+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-06-28 16:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: David Vrabel, xen-devel, LKML, John Stultz
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
@ 2013-06-28 18:58 ` Thomas Gleixner
0 siblings, 0 replies; 12+ messages in thread
From: Thomas Gleixner @ 2013-06-28 18:58 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: David Vrabel, xen-devel, LKML, John Stultz
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
@ 2013-06-28 18:58 ` Thomas Gleixner
0 siblings, 0 replies; 12+ messages in thread
From: Thomas Gleixner @ 2013-06-28 18:58 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: LKML, John Stultz, David Vrabel, xen-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases
2013-06-27 10:35 David Vrabel
2013-06-28 13:14 ` Thomas Gleixner
@ 2013-06-28 13:14 ` Thomas Gleixner
1 sibling, 0 replies; 12+ messages in thread
From: Thomas Gleixner @ 2013-06-28 13:14 UTC (permalink / raw)
To: David Vrabel; +Cc: John Stultz, LKML, xen-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-06-28 19:00 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 10:35 [PATCHv6 0/5] xen: maintain an accurate persistent clock in more cases David Vrabel
-- strict thread matches above, loose matches on Subject: below --
2013-06-27 10:35 David Vrabel
2013-06-28 13:14 ` Thomas Gleixner
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 15:01 ` Konrad Rzeszutek Wilk
2013-06-28 15:12 ` Thomas Gleixner
2013-06-28 15:12 ` Thomas Gleixner
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
2013-06-28 16:19 ` Konrad Rzeszutek Wilk
2013-06-28 18:58 ` Thomas Gleixner
2013-06-28 18:58 ` Thomas Gleixner
2013-06-28 13:14 ` Thomas Gleixner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.