[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHl] localtime basis for paravirtualized guests

No you aren't missing anything ;-)  Simply providing UTC to a linux DomU
by far the simplest way to go, as you point out.  But given that my
creates the option of launching a domain with localtime as its time
(which P.V. NetWare needs), I'm just pointing out what we found to be
additional infrastructure that would be needed to get linux to work
_if_ you wanted to have it correctly work with a localtime time base.

Our SLES 10 YaST module defaults to UTC when creating linux guests,
the option to use localtime is also there, while the additional
mentioned (/dev/rtc support, etc) is, unfortunately, not.  So we are
the moment documenting that linux guests should have their virtual
hardware clocks set to UTC, which is what most everyone would

My patch solves NetWare's needs just fine, but is insufficent for
and I think a much more universal solution than what my patch
is needed longer term.

- Bruce

>>> On 6/21/2006 at 3:45 PM, in message
<9d0d38d120a8176845142085d3822671@xxxxxxxxxxxx>, Keir Fraser
<Keir.Fraser@xxxxxxxxxxxx> wrote:

> I must be missing something. Are you saying we might want to provide
> domU with a localtime RTC, which it reads, offsets to UTC (because it

> knows its timezone), and then uses to set UTC time in its kernel? How

> is that better than what we do now, which is to simply provide UTC
> directly to the kernel, which it can then convert to localtime itself

> when that's appropriate?
>   -- Keir
> On 21 Jun 2006, at 22:23, Bruce Rogers wrote:
>> The way Linux gets its UTC time when it is running from a locatime
>> time base is that hwclock is called from the init scripts and it
>> /dev/rtc, offsets that value by the local time offset, and resets
>> kernel's time via the settimeofday system call.  So if /dev/rtc was
>> tied straight into the time retrieved from Xen (speaking of the
>> DomU case) this all works correctly to reset the kernel's sense
>> of time to be UTC.  As it stands today, hwclock fails because
>> neither /dev/rtc nor direct access to the RTC via port I/O is
>> there for a DomU.
>> Without the above actions taking place, the kernel is left
>> using localtime (from Xen) as if it was UTC, and the
>> localtime derived from that is off.  I've got the rtc.c code
>> hacked up to make it work but before I proceeded down that
>> path further, was interested in hearing what others thought
>> might be the best solution for allowing guests to use Xen as
>> a time basis, but be more flexible with managing its own time.
>> - Bruce
>>>>> On 6/21/2006 at 10:11 AM, in message
>> <220a261ede8f0089ecc6a7c408cea2b8@xxxxxxxxxxxx>, Keir Fraser
>> <Keir.Fraser@xxxxxxxxxxxx> wrote:
>>> On 21 Jun 2006, at 00:20, Bruce Rogers wrote:
>>>> I should point out however that this by itself does not allow a
>>>> localtime
>>>> time base to be used for xenolinux.  That support would require
>>>> additional
>>>> changes to Linux (eg a Xen aware implementation of /dev/rtc &
>> etc.),
>>>> and
>>>> should probably be based on a more flexible and thorough
>> implementation
>>>> of
>>>> non-UTC guest time bases than what this patch provides.
>>> I'm not sure what you mean here. If Xen adds an offset to wc_sec
>>> XenLinux will see a different wallclock time. Right? RTC isn't
>> emulated
>>> or used by domUs.
>>>   -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.