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

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

Are there any conditions/events in a running Xen system
that can cause two consecutive calls to get_s_time()
*on the same processor* to return values such that
the second one is smaller than the first (other than
64-bit wraparound)?  I ask because I'm fairly sure
that I observed this, and Xen system time on the
same processor moved backwards about 40us (40000ns).

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?

Thanks,
Dan

===================================
Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)

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