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

[Xen-devel] Re: s_time going backwards on same processor?

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: s_time going backwards on same processor?
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 26 Jul 2008 07:50:30 +0100
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 25 Jul 2008 23:50:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D95FF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AcjsRiBvfsM2jSzrTdKQFwbDzvcjiQATHBz4AItzXLAAAV3+8AAJg5Qm
Thread-topic: s_time going backwards on same processor?
User-agent: Microsoft-Entourage/11.4.0.080122
The code should be using spin_lock_irqsave/spin_unlock_irqrestore.

As it is it's incorrect and could cause odd behaviour. I don't know whether
that would extend to seeing time goes backwards as often as Dan reports, but
obviously the test has to be re-run.

 -- Keir

On 26/7/08 03:23, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> In a quick glimpse, your measure_stime_skew has interrupt
> enabled absolutely at exit, instead of restoring previous
> setting. Would it be a trouble-maker? I have no latest code
> at hand, but at least for what I can check:
> 
> in local_time_calibration:
> 
>     local_irq_disable();
>     curr_master_stime = read_platform_stime();
>     curr_local_stime  = get_s_time();
>     rdtscll(curr_tsc);
>     local_irq_enable();
> 
> with your patch, interrupt is enabled after get_s_time, which
> then may have curr_tsc read out from a different time point...
> 
> Thanks,
> Kevin
> 
>> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
>> Sent: 2008年7月26日 9:47
>> 
>> OK, I am definitely recording stime going backwards
>> observed with the attached patch.  I have recorded dozens
>> over a few hours.  It appears to have no
>> obvious pattern between reports, but one thing
>> is consistent: In all cases, t->tsc_scale.shift
>> is -1.  I'll try to run some more tests over the
>> weekend (e.g. with different clocksources... this
>> is with clocksource=hpet), but thought I'd report
>> what I have seen.  I'm running on a dual-core single
>> socket ("Conroe").
>> 
>> Dan
>> 
>> P.S. If you try the patch, ensure you set
>> the boot parameter "measurestime".
>> 
>>> -----Original Message-----
>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>>> Sent: Wednesday, July 23, 2008 1:06 AM
>>> To: dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
>>> Cc: Dave Winchell
>>> Subject: Re: s_time going backwards on same processor?
>>> 
>>> 
>>> On 22/7/08 22:58, "Dan Magenheimer"
>>> <dan.magenheimer@xxxxxxxxxx> wrote:
>>> 
>>>> I *do* know that get_s_time() on different processors
>>>> can have this behavior and I know it is possible for
>>>> hvm_get_guest_time() to go backwards (timer_mode=0),
>>>> but I thought s_time was monotonically non-decreasing
>>>> on any given processor and that read_platform_stime()
>>>> is also monotonically non-decreasing.
>>>> 
>>>> Does dom0 maybe have direct hardware access to the hardware
>>>> platform timer that xen system time is dependent on?
>>> 
>>> No matter what happens to the underlying platform timer, it should be
>>> impossible for Xen system time to go backwards on any given
>>> processor. The
>>> calibration function never sets the TSC and system timestamps
>>> for the next
>>> time record any earlier than current TSC value and current
>>> computed system
>>> time value. Hence it should be impossible for system time to
>>> be computed as
>>> earlier than that time record.
>>> 
>>>  -- Keir
>>> 
>>> 
>>> 
>> 



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