I notice, in xen/clock.d:get_time_values_from_xen(), that we're using
__insn_barrier(), which is just a directive to the compiler, where
Linux is using (and my minimal understanding of the architecture would
suggest) an lfence instruction to prevent the CPU from reordering the
loads and breaking the concurrency protocol.

I think it's possible that this could be the cause of some of the
hard-to-reproduce problems I was seeing -- if the 64-bit system_time
counter could be caught in the middle of an update when the lower word
(uh, "dword") is rolling over, that would move the apparent time by
about 4.3s -- and the strange deltas cc_microset had been reporting
(this was before I replaced it) were usually in the 4.3s-5.3s range,
which makes sense because cc_microset is called about once a second.

Thoughts?

-- 
(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)))))