A Timecounter for Xen

I have here a patch that adds timecounter support for xen;
it's been
gathering dust in a local tree of mine for a few months, but
before
life happened and I got sidetracked from it, it stood up to
a fair
amount of testing, and it still works.  The changes, while
mostly
localized, are not trivial, so I'm posting them here.

As always, it returns Xen "system time" --
monotonic nanoseconds since
boot, measured with the x86 cycle counter and scaling
information
provided and maintained by the hypervisor.

The main subtlety is that, because a domain might not be
scheduled to
run until some time after the timer interrupt-equivalent
should occur,
if the MI timecounter tick routine (called under
hardclock(9)) got the
actual times, it could miscompute the conversion to wall
clock time.
Thus, the timer event handler arranges to have those
timecount values
offset by the difference, as if the hardclock tick had
occurred when
it was supposed it.

Also, because such adjustments can't be done for arbitrary
other
timecounters (e.g., ACPI timers in Xen3 dom0), the
xen_system_time
counter assigns itself a very high quality in order to
prevent their
use by default.

It's not SMP-ready at the moment (and hadn't been before
this change),
but that should be fairly easy to add; it'd be mostly a
simple matter
of moving static globals into cpu_info.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x
y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s)
l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car
l)) ((f (cdr l))
(C k)))))))    '((#J #d #D #v #s) (#e #space #a #i
#newline)))))

On Wed, May 09, 2007 at 12:14:37AM -0400, Jed Davis wrote:
> I have here a patch that adds timecounter support for
xen; it's been
> gathering dust in a local tree of mine for a few
months, but before
> life happened and I got sidetracked from it, it stood
up to a fair
> amount of testing, and it still works.  The changes,
while mostly
> localized, are not trivial, so I'm posting them here.
> 
> As always, it returns Xen "system time" --
monotonic nanoseconds since
> boot, measured with the x86 cycle counter and scaling
information
> provided and maintained by the hypervisor.
> 
> The main subtlety is that, because a domain might not
be scheduled to
> run until some time after the timer
interrupt-equivalent should occur,
> if the MI timecounter tick routine (called under
hardclock(9)) got the
> actual times, it could miscompute the conversion to
wall clock time.
> Thus, the timer event handler arranges to have those
timecount values
> offset by the difference, as if the hardclock tick had
occurred when
> it was supposed it.
> 
> Also, because such adjustments can't be done for
arbitrary other
> timecounters (e.g., ACPI timers in Xen3 dom0), the
xen_system_time
> counter assigns itself a very high quality in order to
prevent their
> use by default.
> 
> It's not SMP-ready at the moment (and hadn't been
before this change),
> but that should be fairly easy to add; it'd be mostly a
simple matter
> of moving static globals into cpu_info.

This looks good. Thanks for the work !

-- 
Manuel Bouyer, LIP6, Universite Paris VI.          
Manuel.Bouyerlip6.fr
     NetBSD: 26 ans d'experience feront toujours la
difference
--