Xen devel - Jun 2011 - syncing wall clock time from Dom0 to hypervisor

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?

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).

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Konrad Rzeszutek Wilk  07/13/11 3:52 PM >>>
>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?
I would think so.
>I think the ''sync_cmos_clock'' looks to be doing that. And
the hook
>to the Xen is via ''update_persistent_clock'' call?
The problem is that Xen code overwites the x86_platform.[gs]et_wallclock
hooks, without calling (at least in the set case on Dom0) the original
function afaics.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2011-07-13 at 14:52 +0100, Konrad Rzeszutek Wilk
wrote:
> 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.
Was this what Stefano''s patch from way back was about:
http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00469.html
?

I forget what the issue with it was and the conversation got derailed
about into talking about an adjtimex style hypercall

Ian.
> 
> 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?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel