[PATCH] Have xen dom0 still handle time of 1970

[PATCH] Have xen dom0 still handle time of 1970

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

It's come to our attention, that the time gets screwed up when set 
between EPOCH and EPOCH + uptime.  This may not seem important (because 
we don't live in the 70s anymore) but it makes LTP fail.  LTP has a date 
test that checks what happens when set to EPOCH + 100 secs + 100 nsecs, 
and makes sure that it gets a proper result.

The following patches helps xen handle the case where time is set back 
to Jan 1st 1970 (or anytime from EPOCH to EPOCH + uptime).

Here's what you get without the patch:

# date -u 010100011970
Thu Jan  1 00:01:00 UTC 1970
# date
Mon Feb 22 16:42:30 EST 2010

Here's what you get with the patch:

# date -u 010100011970
Thu Jan  1 00:01:00 UTC 1970
# date
Wed Dec 31 19:01:01 EST 1969

-- Steve

Signed-off-by: Steven Rostedt <srostedt@redhat.com>

[-- Attachment #2: xen-epoch-time-set.patch --]
[-- Type: text/x-patch, Size: 2493 bytes --]

diff -r fd2667419c53 linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
--- a/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c	Tue Jan 16 14:04:12 2007 -0500
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c	Wed Jan 17 10:34:06 2007 -0500
@@ -260,7 +260,8 @@ static void __update_wallclock(time_t se
 {
 	long wtm_nsec, xtime_nsec;
 	time_t wtm_sec, xtime_sec;
-	u64 tmp, wc_nsec;
+	s64 tmp, wc_nsec;
+	int s;
 
 	/* Adjust wall-clock time base based on wall_jiffies ticks. */
 	wc_nsec = processed_system_time;
@@ -270,8 +271,17 @@ static void __update_wallclock(time_t se
 
 	/* Split wallclock base into seconds and nanoseconds. */
 	tmp = wc_nsec;
+	/*
+	 * do_div does not like s64, and treats them as u64
+	 * and we will not get the expected result.
+	 * So for those with time machines, let 1970 work
+	 * again!
+	 */
+	s = tmp < 0 ? -1 : 1;
+	tmp *= s;
 	xtime_nsec = do_div(tmp, 1000000000);
 	xtime_sec  = (time_t)tmp;
+	xtime_sec *= s;
 
 	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - xtime_sec);
 	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - xtime_nsec);
@@ -289,7 +299,12 @@ static void update_wallclock(void)
 	do {
 		shadow_tv_version = s->wc_version;
 		rmb();
-		shadow_tv.tv_sec  = s->wc_sec;
+		/*
+		 * If someone decides to set the time to something
+		 * before EPOCH + uptime, we can get a negative
+		 * number here.
+		 */
+		shadow_tv.tv_sec  = (s32)s->wc_sec;
 		shadow_tv.tv_nsec = s->wc_nsec;
 		rmb();
 	} while ((s->wc_version & 1) | (shadow_tv_version ^ s->wc_version));
diff -r fd2667419c53 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Tue Jan 16 14:04:12 2007 -0500
+++ b/xen/arch/x86/time.c	Wed Jan 17 10:34:06 2007 -0500
@@ -708,12 +708,23 @@ void update_domain_wallclock_time(struct
 /* Set clock to <secs,usecs> after 00:00:00 UTC, 1 January, 1970. */
 void do_settime(unsigned long secs, unsigned long nsecs, u64 system_time_base)
 {
-    u64 x;
+    s64 x;
     u32 y, _wc_sec, _wc_nsec;
     struct domain *d;
+    int s;
 
     x = (secs * 1000000000ULL) + (u64)nsecs - system_time_base;
+    s = x < 0 ? -1 : 1;
+    /*
+     * do_div does not like negative s64 numbers and treats them
+     * as u64, thus the result is unexpected if the s64 is
+     * negative. For those that still live in the 70s, and
+     * want their Xen boxes to do the same, we must handle the
+     * negative case.
+     */
+    x *= s;
     y = do_div(x, 1000000000);
+    x *= s;
 
     spin_lock(&wc_lock);
     wc_sec  = _wc_sec  = (u32)x;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Have xen dom0 still handle time of 1970

[Keir Fraser]

On 17/1/07 15:50, "Steven Rostedt" <srostedt@redhat.com> wrote:

> Here's what you get without the patch:
> 
> # date -u 010100011970
> Thu Jan  1 00:01:00 UTC 1970
> # date
> Mon Feb 22 16:42:30 EST 2010
> 
> Here's what you get with the patch:
> 
> # date -u 010100011970
> Thu Jan  1 00:01:00 UTC 1970
> # date
> Wed Dec 31 19:01:01 EST 1969

The Xen interface is defined relative to UTC, not local time zone, so
negative numbers shuld not be involved if you are setting a time value after
the epoch (which you are). Perhaps our assumption that xtime is a UTC
variable is broken? If that's the case, is there a way to translate between
local time zone and UTC inside the kernel? If not we have a bit of a problem
since it really makes sense for Xen to work in UTC and let each guest apply
its own time-zone transformation.

 -- Keir

Re: [PATCH] Have xen dom0 still handle time of 1970

[Steven Rostedt]

Keir Fraser wrote:
> On 17/1/07 15:50, "Steven Rostedt" <srostedt@redhat.com> wrote:
> 
>> Here's what you get without the patch:
>>
>> # date -u 010100011970
>> Thu Jan  1 00:01:00 UTC 1970
>> # date
>> Mon Feb 22 16:42:30 EST 2010
>>
>> Here's what you get with the patch:
>>
>> # date -u 010100011970
>> Thu Jan  1 00:01:00 UTC 1970
>> # date
>> Wed Dec 31 19:01:01 EST 1969
> 
> The Xen interface is defined relative to UTC, not local time zone, so
> negative numbers shuld not be involved if you are setting a time value after
> the epoch (which you are). Perhaps our assumption that xtime is a UTC
> variable is broken? If that's the case, is there a way to translate between
> local time zone and UTC inside the kernel? If not we have a bit of a problem
> since it really makes sense for Xen to work in UTC and let each guest apply
> its own time-zone transformation.
> 

It doesn't matter about the TZ. If I do this on a machine that has been 
running xen for more than a day, it will still fail with setting date to

date -u 010123001970

Which is not effected by the TZ (the result is after EPOCH).

The problem is that the calculation uses the uptime and compares that 
with the given time past EPOCH (using UTC).  So if that time is less 
than uptime, it will fail the time conversion.

Have a box with Xen running more than a day? (I currently don't), and if 
you do, try the above date command. You'll see what I'm talking about.

The example is bad, but I didn't have a machine to show that has been 
running a Xen kernel for more than an hour or two.

-- Steve

Re: [PATCH] Have xen dom0 still handle time of 1970

[Keir Fraser]

On 17/1/07 16:30, "Steven Rostedt" <srostedt@redhat.com> wrote:

> Have a box with Xen running more than a day? (I currently don't), and if
> you do, try the above date command. You'll see what I'm talking about.
> 
> The example is bad, but I didn't have a machine to show that has been
> running a Xen kernel for more than an hour or two.

Oh, I see. But it kind of feels silly to work around a synthetic correctness
test. If we make wc_sec implicitly signed (which is pretty gross) then we
lose 1 bit of magnitude which also isn't great -- I'd rather be able to
represent years 2038 through 2106 than 1902 through 1970.

What we could do, to keep LTP happy, is set the local domain's time as
specified but clamp the time sent to Xen at epoch+uptime. This would require
dom0 to read wc_time from Xen only once at boot. OTOH perhaps we just do not
really care -- after all by default this LTP test will fail on all domU
because settimeofday() is a no-op unless /proc/sys/xen/independent_wallclock
is asserted. And if you set that flag on dom0, the LTP test will magically
start working there too! :-)

Perhaps at least we should fail or clamp the settimeofday() call, rather
than doing some mad warp into the future...

 -- Keir

Re: [PATCH] Have xen dom0 still handle time of 1970

[Rik van Riel]

Keir Fraser wrote:
> On 17/1/07 16:30, "Steven Rostedt" <srostedt@redhat.com> wrote:
> 
>> Have a box with Xen running more than a day? (I currently don't), and if
>> you do, try the above date command. You'll see what I'm talking about.
>>
>> The example is bad, but I didn't have a machine to show that has been
>> running a Xen kernel for more than an hour or two.
> 
> Oh, I see. But it kind of feels silly to work around a synthetic correctness
> test. If we make wc_sec implicitly signed (which is pretty gross) then we
> lose 1 bit of magnitude which also isn't great -- I'd rather be able to
> represent years 2038 through 2106 than 1902 through 1970.

Isn't unsigned long 64 bits on 64 bit systems anyway?

That would give us a lot more time...

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

Re: [PATCH] Have xen dom0 still handle time of 1970

[Keir Fraser]

On 17/1/07 17:36, "Rik van Riel" <riel@redhat.com> wrote:

>> Oh, I see. But it kind of feels silly to work around a synthetic correctness
>> test. If we make wc_sec implicitly signed (which is pretty gross) then we
>> lose 1 bit of magnitude which also isn't great -- I'd rather be able to
>> represent years 2038 through 2106 than 1902 through 1970.
> 
> Isn't unsigned long 64 bits on 64 bit systems anyway?
> 
> That would give us a lot more time...

Yeah it is, but wc_sec in shared_info is uint32_t. Perhaps I wasn't
optimistic enough about Xen's longevity. :-) With tricks we could be good
out to about 2250 without needing to increase wc_sec's size.

 -- Keir