No you aren't missing anything ;-) Simply providing UTC to a linux DomU
is
by far the simplest way to go, as you point out. But given that my
patch
creates the option of launching a domain with localtime as its time
base
(which P.V. NetWare needs), I'm just pointing out what we found to be
the
additional infrastructure that would be needed to get linux to work
correctly
_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,
but
the option to use localtime is also there, while the additional
infrastructure
mentioned (/dev/rtc support, etc) is, unfortunately, not. So we are
for
the moment documenting that linux guests should have their virtual
hardware clocks set to UTC, which is what most everyone would
naturally
do.
My patch solves NetWare's needs just fine, but is insufficent for
linux,
and I think a much more universal solution than what my patch
implements
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
a
> 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
time
> 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
reads
>> /dev/rtc, offsets that value by the local time offset, and resets
the
>> 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
then
>>
>>> XenLinux will see a different wallclock time. Right? RTC isn't
>> emulated
>>> or used by domUs.
>>>
>>> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home