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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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