[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xen-devel] System time monotonicity



On 10/4/08 22:27, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> 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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.