RE: System time monotonicity

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

> >> This is all true. The logic in vpt.c should be fixed to use
> >> Xen's concept of
> >> system time and everything, guest TSC included, should be
> >> derived from that.
> >
> > Does Xen's concept of system time have sufficient resolution
> > and continuity to ensure both monotonicity and a reasonable
> > guest timer granularity?  I'm thinking not; some form of
> > interpolation will probably be necessary which will require
> > reading a physical platform timer** (e.g. other than tsc).
> 
> Xen's system time provides nanosecond precision and is 
> intended to be as
> accurate as the underlying platform timer (over long periods) and as
> granular and accurate as the TSC over sub-second periods. 
> It's quite good enough for any guest purposes.

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.

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.