Manuel Bouyer <bouyer@antioche.eu.org> writes:

> On Fri, Jan 13, 2006 at 11:21:58PM -0500, Jed Davis wrote:
>> Problem 1: It's still completely ignoring time(9), which is very wrong
>> AIUI; and resettodr() is a no-op, which makes it worse.
>
> AFAIK, time(9) is properly handled by hardclock(), and resettodr() can't
> be anything but a no-op on a domU.

Right, there's nothing resettodr() can reasonably do; I mentioned it
because the combination of both that and ignoring time(9) made
ntpdate(8) be a no-op, which was somewhat surprising.

>> Problem 2: I tried this, and the shadow_tv was 42 seconds fast and
>> drifting slowly but noticeably forward; the dom0 was running ntpdate
>> from cron and was on time.  (Hm... the DOM0_SETTIME is called only
>> when resettodr() is, so if the drift is small enough for ntpdate to
>> always use adjtime(2), it won't ever correct Xen's time?)
>
> Maybe not, until the system is rebooted. But I'm not sure it's desireable to
> correct the time this way. This would make the time go sometime backward
> in the domU.
> I checked Xen3, there isn't a way to correct the clock drift in the
> hypervisor. We can just set the time to a new value.

I looked over Linux's clock code, at Thor's suggestion; it will set
the Xen clock from the dom0 every so often if needed, and has some
measures to keep the clock from going backwards no matter what
(barring settimeofday, of course).  I'd have to stare at it more to be
more specific than that.

Linux also has a sysctl-alike for whether to use Xen's time or to have
an independent clock.

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