Re: [PATCHl] localtime basis for paravirtualized guests

["Bruce Rogers" <BROGERS@novell.com>]

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@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> 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