RE: System time monotonicity

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

> If we wanted to be more certain we could maintain a 
> last_system_time fields per VCPU and

If you mean per VCPU *and* per guest this seems like
a good idea.

> backwards, by turning small backwards deltas into very short 
> periods of stalled time.

The stalled time may be a problem, but only if the tsc skew
between processors is "bad".  Your estimate of 100us seems
like it could be unacceptable for some applications.

Any idea how expensive arch/x86/time.c:local_time_calibration()
is?  If it's not too bad, one option might be to add a xen
boot parameter "calibratehz" to calibrate more frequently.
Then systems running time-sensitive guests can be instructed
to increase the parameter accordingly to ensure tsc skew
is small enough.

> > 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.
> 
> If we wanted to be more certain we could maintain a 
> last_system_time fields
> per VCPU and, whenever using system time to compute current 
> value for a
> virtual timer for an HVM VCPU, we could actually use max(system time,
> last_system_time). This would mean we were 100% sure that 
> time didn't go
> backwards, by turning small backwards deltas into very short 
> periods of
> stalled time.
> 
> As it is: no, since system time 'free runs' on each CPU over 
> one-second
> periods, there can be drift between CPUs if they are driven 
> by different
> oscillators. Also there are tolerances in our software 
> calibration code to
> consider. Which is why Linux guests implement the max(curr 
> time, last time)
> in their gettimeofday() code. It would be quite reasonable to 
> the same,
> inside Xen, for HVM guests. We can at least be pretty certain that any
> drifts across CPUs/VCPUs will be on the order of less than 100us.
> 
>  -- Keir
> 
> 
>