Currently domU live migration between two hosts is
broken. The guest's
system clock (implemented in arch/i386/kernel/time-xen.c) is pulled
directly from xen so time will typically change significantly when
moving between two xen instances. In older versions of the xen patches
this works fine but these 2.6.22 patches have replaced the old
do_gettimeofday implementation with the GENERIC_TIME implementation
which gets the time from the new xen_clocksource_read function. The
problem is that xen_clocksource_read makes sure that time never goes
backwards, either returning the new time if it went forwards or the
previous read if time appears to have gone backwards. So when the system
time jumps backwards during a move to a new physical machine suddenly
time stops. I've worked around the issue for now by replacing time-xen.c
with an older version from redhat's 2.6.21 xen kernel and disabling
GENERIC_TIME. The attached patch does this for i386 but it leaves x86_64
broken since I haven't gotten to that yet.
Hmm, indeed, that is a case where insisting on monotonicity is a problem,
For kicks I tried letting xen_clocksource_read return a
time in the past
but that caused the kernel to get lost in an endless loop somewhere.
Perhaps the system time should be kept locally within the kernel instead
of pulling directly from xen and updated during the timer tick's wall
clock update. Then xen_clocksource_read would use that time plus the
change in TSC since the last tick instead of xen's time.
... that is exactly why monotonicity is required (there is a calculation
somewhere in generic code [I debugged this a while back, but don't
recall without in-depth checking] that creates huge positive timeouts
when time stamps move a tiny bit backwards, but since as said this is
in generic code that I understand at best half ways it didn't seem
reasonable to change the behavior there).
Going back to the non-generic-time handling is not really a solution here,
instead I'm already feeling quite nervous about GENERIC_CLOCKEVENTS & Co
being suppressed for Xen (but I don't think changing this would help the
issue you raise) - I simply didn't have a chance to educate myself enough
about this new time infrastructure.
So I think the issue should rather be taken care of in the resume path
(where, without checking the code) I assume generic code is capable
of dealing with time moving backwards.
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org