RE: [xen-devel] System time monotonicity

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

> > OK, as long as the maximum uncorrected drift between physical TSCs
> > does not exceed the guest-expected granularity of its virtual
> > platform timer, I agree its good enough.
> 
> Ignoring power-saving events, TSCs are crystal-driven and hence we can
> expect specified tolerance of a few ppm across temperature 
> extremes, and in
> practice over few-second periods I would expect tolerance of 
> better than
> 1ppm. *However* I have seen platform timers (which also should be
> crystal-driven) which inexplicably exhibit much worse behaviour.

OK... back to monotonicity for a moment:

So regardless of ppms and thermal and P-state and drifts,
are you confident that the current corrected-tsc mechanism
will never see time going backwards for the following test?
(Apologies for pseudo-code, but hope you get the drift...
pun intended).

global val1, proceed = 0;

Guest thread 1:
spin_lock(lock);
val1 = read_hpet();
proceed = 1;
spin_unlock(lock);

Guest thread 2:
while (!proceed);
spin_unlock_wait(lock);
val2 = read_hpet();
if (val2 < val1) PANIC();

If you are not confident that this will be OK on existing and
(within-reason) future Xen platforms, perhaps the hvm virtual
platform timers should (at least optionally) be built on physical
platform timers (Dave Winchell cc'ed), which would ensure time
never goes backwards.

> > It appears that TSC drift for each pcpu is corrected by Xen
> > once per second.  Any idea for real systems out there what the
> > maximum drift (per second) is?  Will this be affected by
> > existing or future power-savings designs (e.g. is it possible
> > for the TSCs in one socket to be slowed down while the TSCs
> > in another socket are not)?  If so, as Kevin points out,
> > some kind of affinity enforcement might be necessary for
> > time-sensitive VMs.
> 
> P-state changes are informed to Xen so we can re-sync the local TSC
> immediately. The tricky ones are unannounced thermal events 
> because software
> does not get informed about those. On some systems we can 
> turn them off, on
> others (new Intel platforms) TSC is constant-rate regardless. 
> In a normal
> running system thermal events are rare.

If it is possible to write code that can determine at
boot-time (or at hotplug cpu_online) what CPUs are
guaranteed-sync'ed with what other CPUs, it would be
nice if this information was exported by Xen
so that tools can manage very-time-sensitive guests
appropriately.

Personally, I think this code should be provided by the
CPU vendors ;-)

Dan


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