From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU Date: Wed, 13 Oct 2010 09:02:14 -0700 Message-ID: <4CB5D806.7000609@goop.org> References: <9C56B6AEEB2D60488B29B880DF7E53BE03C1B2C6B6@SSDEXCH2.websense.com> <4CB4672E020000780001C752@vpn.id2.novell.com> <9C56B6AEEB2D60488B29B880DF7E53BE03C1B2C8F6@SSDEXCH2.websense.com 4CB5C43C020000780001CD39@vpn.id2.novell.com> <0b6cc1b3-f838-482e-89dc-6f19cc8c47cc@default> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0b6cc1b3-f838-482e-89dc-6f19cc8c47cc@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, Keir Fraser , Shunli Yi , Jan Beulich , Saipu Liu , Hang Du List-Id: xen-devel@lists.xenproject.org On 10/13/2010 08:56 AM, Dan Magenheimer wrote: > (bringing the topic up to a more theoretical level and including > Keir and Jeremy) > > I wonder if the "bug" here is that "dependent wall clock" is > an incredibly poor replacement for NTP (or a Windows Time Server) > and a hack and really shouldn't even exist? I suppose one could > argue that it makes some sense in a XCP environment, and maybe > in a server environment where a single physical server is extremely > isolated, but does it ever make sense in a real world server > environment? > > In other words, I'm arguing that the correct "fix" here is: > Don't use dependent wallclock. Yes, that's always been my view. pvops kernels don't implement it. J >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@novell.com] >> Sent: Wednesday, October 13, 2010 6:38 AM >> To: Hang Du >> Cc: Saipu Liu; Shunli Yi; xen-devel@lists.xensource.com >> Subject: RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when >> sync up time from dom0 to domU >> >>>>> On 13.10.10 at 05:24, "Du, Hang" wrote: >>> Sorry for my brief description in previous mail and missing >>> is_initial_xendomain check. The kernel I submit this patch is >>> linux-2.6.18-xen-3.4.2, I submit the patch again with in_initial- >> xendomain >>> check. >> Actually, I didn't expect you to blindly insert that check, but rather >> either explain why only DomU-s need the changed behavior (as your >> original description suggested), or refine the description of the >> problem you're trying to solve. >> >>> In this patch, we support the backward time changing sync to all >> domUs which >>> configured to use "dependent wall clock". >>> Currently, without the backward time syncing, when we change the time >>> backward in Dom0, the time in DomU would be froze. >>> And this cause some commands hang and don't executed until the time >> catch up >>> with the domU time. >>> For example: >>> "rpm -q kernel-xen" >>> "sleep 1" >>> Monotonic time should be reset when sync up time from dom0 to domU to >>> support domU backward time syncing. >> I can see your point, however ... >> >>> diff -urN a/arch/i386/kernel/time-xen.c b/arch/i386/kernel/time- >> xen.c >>> --- a/arch/i386/kernel/time-xen.c 2010-10-11 10:41:06.000000000 >> +0800 >>> +++ b/arch/i386/kernel/time-xen.c 2010-10-11 10:43:32.000000000 >> +0800 >>> @@ -715,6 +715,8 @@ >>> } >>> >>> if (shadow_tv_version != HYPERVISOR_shared_info->wc_version) { >>> + if (!is_initial_xendomain() && !independent_wallclock) >>> + monotonic_reset(); >>> update_wallclock(); >> ... you definitely need to call monotonic_reset() *after* the >> update_wallclock() (or else another vCPU, preempted in >> do_gettimeofday() between the end of the xtime read loop >> and the acquiring of the monotonic lock, would be able to >> overwrite monotonic.tv with values obtained before the wall >> clock update - similar to the secondary problem addressed by >> c/s 1021). >> >> Further, blindly running a reset here doesn't seem nice in >> the (general) case of the time getting updated forwards. >> >>> schedule_clock_was_set_work = 1; >>> } >> You'll also want to address Dan's concerns, and you will want to >> get your patch formatted so that it would actually apply (read: >> no tab -> space conversion) if you expect it to be committed >> by Keir at some point. >> >> Jan >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel