From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [PATCH] [PVOPS] dom0 sync xen wallclock Date: Wed, 10 Feb 2010 16:47:48 -0800 Message-ID: <4B7353B4.4000600@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian Campbell , "xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 02/10/2010 04:06 PM, Keir Fraser wrote: > A Xen ABI for adjtime()-alike warping of Xen system time is something we > should add at some point, as that's the logical thing for ntp in dom0 to > affect, keeping the system's 'nanosecond ticker' in sync with the wider > world. Hm. I think it would be best to keep the ticker unchanged, but perhaps offer a mechanism so that dom0 can set separate offset and drift parameters which other domains can query to may system time to global time. But I don't think even that is a very compelling idea. > That'd keep all domU clocks in sync, all except for fixed wallclock > offsets. But it doesn't currently exist, so instead it gets bunged in with > Xen's existing settimeofday()-alike interface: hence domUs either can see > discontinuities, or don't get the automatic benefits of ntp sync at all, > because they only read the wallclock offset at boot time. > I suppose. All the domains can already run ntp if you really want to keep them in sync with each other and/or dom0 and/or the outside world. I'm not sure there's much point in making Xen ABI changes in this area; anything we do will come down to being a partial and probably inadequate reimplementation of ntp (esp when you consider how to deal with migration). J