Xen devel - Jan 2007 - [PATCH] Have xen dom0 still handle time of 1970

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>


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

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


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

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


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

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


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

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.

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

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


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