WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up tim

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Hang Du <hdu@xxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU
From: Keir Fraser <keir@xxxxxxx>
Date: Wed, 13 Oct 2010 17:09:34 +0100
Cc: Saipu Liu <saliu@xxxxxxxxxxxx>, Shunli Yi <syi@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 13 Oct 2010 09:10:38 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=lAoDwfsrlXN9R7i2FRAvxpRpZShIulPV4wU93IQ+w/U=; b=PcAv2toZD25XTFrizmR5o9ihiDH7oLiwPl26lkaezW5Y/IWjItSCNOGeSDLDyEbTbx zM95AVzdfJljxdbQrg2CVFUs2hP8FRJw02fN6Mt1ketTG4Q08hc1ROIvgswu20Q2pVwd h9GQRBvEILLscKAwK5F4xFb1pAQ43XEGLajPc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=qmG076baTMr+ckL/xGA615XRa2h/wavyQcZ6n49mvFA6aIKILwNZ4c3BMpoRtlc5Zw m/iofVipRQlwRT4aXIg7HDVMLL1eIw3I355dCRzEF7fffrL5fz0QONXygJ3epIjCStgr not5qDONgLbs1dRZt4Z1kLpSOMTbk5as+3SXE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0b6cc1b3-f838-482e-89dc-6f19cc8c47cc@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Actq8QaQ0ATezFtOEkWMTQLTo+XS3w==
Thread-topic: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU
User-agent: Microsoft-Entourage/12.26.0.100708
On 13/10/2010 16:56, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 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?

Yes it's a bad replacement for ntp. Pv_ops doesn't bother to implement it,
syncs with Xen wallclock once during boot and thereafter expects ntp to be
used within the guest.

 -- Keir

> In other words, I'm arguing that the correct "fix" here is:
> Don't use dependent wallclock.
> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>> Sent: Wednesday, October 13, 2010 6:38 AM
>> To: Hang Du
>> Cc: Saipu Liu; Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx
>> 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" <hdu@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel



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

<Prev in Thread] Current Thread [Next in Thread>