From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: syncing wall clock time from Dom0 to hypervisor
Date: Wed, 13 Jul 2011 09:52:35 -0400
Message-ID: <20110713135235.GB8466@dumpdata.com>
References: <4E0C6911020000780004B45B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <4E0C6911020000780004B45B@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jan Beulich <JBeulich@novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

On Thu, Jun 30, 2011 at 11:16:17AM +0100, Jan Beulich wrote:
> While in the upstream kernel I'm unable to find any use of XENPF_settime
> (and the DOM0_SETTIME alias of it) at all, in the 2.6.18 tree (and the
> forward ports of it) the function gets used only when ntp_synced()
> returns true (and - that's minor - when independent_wallclock is not
> set).
> 
> It would however seem to me that this doesn't cover the case where
> the host clock gets adjusted by the Dom0 admin. Is there perhaps
> someone who remembers whether this was implemented the way it
> is intentionally?

<groan> I think we just forgot.

Looking at xen_set_wallclock it just looks as we need to make it do
a similar hypercall as the sync_xen_wallclock to update it?

> 
> There's no such restriction in Jeremy's tree, but that tree also doesn't
> seem to be doing updates at regular intervals (for NTP), nor does it
> look like the CMOS clock would get updated here at all (i.e. I can't
> really take this as a proper reference either).

I think the 'sync_cmos_clock' looks to be doing that. And the hook
to the Xen is via 'update_persistent_clock' call?