On Tue, Feb 28, 2006 at 11:12:21PM -0500, Jed Davis wrote:
> I've attached a patch that changes the microtime function used under
> Xen from cc_microtime to a xen_microtime that's actually useful -- it
> extrapolates from the last step made by hardclock(9) by combining the
> Xen system_time "left over" after the last call to hardclock(9) with
> the CPU counter difference from when the system_time was last updated.
> 
> This works out to be a lot like cc_microtime, except that it uses
> Xen's idea of the CPU frequency instead of trying to measure it using
> the clock interrupt -- which latter, since the "clock interrupt" here
> might be delivered with a certain amount of jitter even in
> non-degenerate cases, seems like a bad idea.
> 
> There is also a check to keep the clock from going backwards by
> clamping the returned time; this applies for only backsteps of <1s,
> because (as the accompanying XXX comment states) I haven't attempted
> to specifically exempt administrative settimeofday use, and also out
> of general paranoia (i.e., something I haven't thought of goes wrong,
> and then the clock spends a few hours stopped, and I find out the hard
> way the next morning).  This will be triggered in the case where the
> time(9) clock speed is reduced, e.g. by the start or end of an
> adjtime(2) adjustment; the extrapolation overshoots what hardclock(9)
> actually does at the end of that tick, and so winds up a few
> microseconds fast just that once.  (For the rest of the adjustment,
> it's fine.)  This could probably be handled more elegantly.
> 
> The XEN_CLOCK_DEBUG define may of course be removed if one doesn't
> want to get a printf whenever the above check is triggered.
> 
> This may not be even remotely correct as far as MP is concerned.
> 
> I don't know what the implications of timecounters on this will be; in
> any case, the release branches won't have timecounters.

Hi,
this looks good to me. Probably better than my attempt to use the
MI cc_microtime() for this (less arithmetic).
Some of your asserts may be wrong for Xen3, where shadow_system_time is
not updated as often (maybe only once a second, I don't remember exactly).
I'll have to check this.
But please commit this if it gives the expected results for you.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--