> > This simple one-line patch changes hvm guest time from
> > monotonically non-decreasing to monotonically strictly-
> > increasing. As a result, two consecutive reads of the
> > (virtual) hpet will never return the same value, thus
> > avoiding the appearance that time has stopped (which may
> > occur if there is skew between physical processor TSCs).
>
> It does seem a little hack-ish, if we don't know of any
> issues arising from
> the current code, and we expect cross-cpu deltas to be pretty
> small.
Using "xm debug-key t; xm dmesg | tail -1" you can get an idea
of the deltas. Even on my single-socket dual-core recent-vintage
Intel box, I'm frequently seeing Diff's > 300ns. While this
is still relatively small (and part of it may be SMP cache
synchronization time), this is supposed to be a "good TSC"
box.
I'm spinning a small patch capturing the maximum so that can
be output via debug-key t also.
> Also
> guests will often convert HPET reads to well-known units (e.g.,
> microseconds, milliseconds) before using them, in which case
> even a delta of
> one may not result in differing converted time values.
Yes, but most newer Linux systems have a high-res timer API
that returns nanoseconds, though admittedly it is not widely
used yet.
Thanks,
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home