Sure, I understand the impacts of the time flag, but that’s the same as the standard Linux.
We just allow the backward time changing sync to all domUs which configured to use “dependent wall clock”.
We suppose the dom0 admin always know what they are doing. In case, if the sysadmin change the time forward by mistake, he/she can fix the time backward.
Currently, without the backward time syncing, when we change the time backward in Dom0, the time in DomU would be froze.
And this cause some commands hang and don’t executed until the time catch up with the domU time.
“rpm -q kernel-xen”
Also, all scripts include these commands would be stuck.
Any further risks impact with the stability or functionality of Xen or kernel ?
From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
Sent: 2010年10月9日 2:50
To: Yi, Shunli; Xen Devel
Subject: RE: [Xen-devel] Allow the backward time syncing in domU.
If time is allowed to jump backwards on ANY computer system, bad things can happen. Consider a “make” where the source file is edited after a backwards-time-jump but before time catches up to when the object file was last generated. The “make” process would get VERY confused. There are many cases like this where programs assume that time is monotonically increasing and would fail miserably if time jumps backwards.
While one cannot stop a sysadmin from causing time to go backwards on dom0, it would be a bad idea for this sysadmin error to be propagated to all guests. I think this is the purpose of disallowing backward time syncing.
From: Yi, Shunli [mailto:syi@xxxxxxxxxxxx]
Sent: Friday, October 08, 2010 3:59 AM
To: Xen Devel
Subject: [Xen-devel] Allow the backward time syncing in domU.
When we use dependent clock in domU, the time syncing from Dom0 to DomU is monotonic (in xenified kernel 18.104.22.168 ).
While, when I read the source code of arch/i386/time-xen.c, I think we can allow the backward time syncing by reset the monotonic time value (monotonic.tv) when the HYPERVISOR_shared_info->wc_version is changed.
I’ve tested that, whenever the Dom0 time changed, the domU’s time would be sync-ed immediately. (with /proc/sys/xen/independent_wallclock=0 ).
So, seems it works perfect, it’s a real dependent wall clock now.
It’s easy to implement the backward time syncing.
So, I wonder that, are there some risks to allow the backward time syncing?
If there isn’t known risk, I’d like to send a patch to allow the backward time syncing.
Could you anybody can help to understand the risks?
Any input is appreciated.
Protected by Websense Hosted Email Security ― www.websense.com
Click here to report this email as spam.