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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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