Re: [PATCH 3/3] xen/privcmd: add IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Oct 12, 2012 at 05:14:16PM +0100, David Vrabel wrote:
> On 12/10/12 16:02, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
> >> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel <david.vrabel@citrix.com> wrote:
> >>>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> >>>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> >>>>>> From: David Vrabel <david.vrabel@citrix.com>
> >>>>>>
> >>>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
> >>>>>> time.
> >>>>>>
> >>>>>> This may be used by the tools to ensure that newly created domains see
> >>>>>> the correct wallclock time if NTP is not used in dom0 or if domains
> >>>>>> are started before NTP has synchronized.
> >>>>>
> >>>>> So... how does this work with NTPD? As in does ntpd _not_ update the
> >>>>> hwclock enough?
> >>>>
> >>>> Once NTPD is synchronized then the kernel updates the wallclock (and the
> >>>> RTC with patch #1) every 11 mins.  I assume this is often enough given
> >>>> how NTP adjusts the system time.
> >>>>
> >>>> You only really need the tools to sync wallclock if system time was
> >>>> stepped at start of day.  e.g., init scripts could do something like:
> >>>>
> >>>> ntpdate pool.ntp.org
> >>>> hwclock --systohc
> >>>> xen-wallclock --systowc
> >>>
> >>> I think I am missing something. The hwclock should end up in the
> >>> xen_set_wallclock call. And from there on, the ntpd would update the
> >>> wallclock if it got skewed enough? Or is the system time not calling
> >>> the wall-clock enough? If that is the case, would just adding this in
> >>> the crontab be enough:
> >>
> >> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
> >> call update_persistent_clock() (or xen_set_wallclock()).
> > 
> > /me scratches his head.
> > 
> > I recall that the update_persistent_clock() was being called.. with
> > hwclock -w (which is the same as --systohc).
> 
> No,
> 
> > That seems like a bug in the generic code - I would think that
> > hwclock would update the wallclock, not just the RTC.
> 
> If we wanted hwclock to also update the xen wallclock we would need a
> xen-specific rtc driver that updated both rtc and wallclock.
> 
> > Oh, it is whoever calls 'adjtimex' syscall ends up calling in
> > update_persistent_clock(). So .. ntpdate or ntpd don't call that?
> 
> ntpd does call adjtimex so if you are running ntpd and it is
> synchronized to its clock source you do get the periodic sync of the
> wallclock.

So, having both ntpd (which calls call adjtimex) - which would run in the
background; and hwclock run at startup - (which updates the RTC, which ends
 - I hope - being trapped by the hypervisor), we end up with the correct
time, right?