All of lore.kernel.org
 help / color / mirror / Atom feed
* syncing wall clock time from Dom0 to hypervisor
@ 2011-06-30 10:16 Jan Beulich
  2011-07-13 13:52 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2011-06-30 10:16 UTC (permalink / raw)
  To: xen-devel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: syncing wall clock time from Dom0 to hypervisor
  2011-06-30 10:16 syncing wall clock time from Dom0 to hypervisor Jan Beulich
@ 2011-07-13 13:52 ` Konrad Rzeszutek Wilk
  2011-07-13 15:17   ` Ian Campbell
  0 siblings, 1 reply; 4+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-07-13 13:52 UTC (permalink / raw)
  To: Jan Beulich; +Cc: 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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: syncing wall clock time from Dom0 to hypervisor
  2011-07-13 13:52 ` Konrad Rzeszutek Wilk
@ 2011-07-13 15:17   ` Ian Campbell
  0 siblings, 0 replies; 4+ messages in thread
From: Ian Campbell @ 2011-07-13 15:17 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: xen-devel, Jan Beulich

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: syncing wall clock time from Dom0 to hypervisor
@ 2011-07-13 14:37 Jan Beulich
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2011-07-13 14:37 UTC (permalink / raw)
  To: konrad.wilk; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]

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


[-- Attachment #1.2: HTML --]
[-- Type: text/html, Size: 814 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-07-13 15:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-30 10:16 syncing wall clock time from Dom0 to hypervisor Jan Beulich
2011-07-13 13:52 ` Konrad Rzeszutek Wilk
2011-07-13 15:17   ` Ian Campbell
2011-07-13 14:37 Jan Beulich

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.