Xen devel - Mar 2006 - wallclock time for paravirtualized guests

The paravirtualized guests are offered wallclock time referenced to UTC only,
while fully virtualized guests are given the option via the config file
(localtime parameter) of starting with UTC time or local time.
What would it take to optionally provide localtime to the paravirtualized guests
as well?
For a guest that launches assuming localtime as its time basis, then later
deriving UTC from it based on configuration files, this is problematic,
requiring some convolutions to how it handles time as it boots.
Is there some place where we can insert a localtime offset into the start-of-day
structure, or perhaps change the sharedinfo wallclock time to be either
localtime or utc, depending on a localtime parameter in the config file, similar
to what is done for fully virtualized guests?
 
- Bruce Rogers


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

> The paravirtualized guests are offered wallclock time 
> referenced to UTC only, while fully virtualized guests are 
> given the option via the config file (localtime parameter) of 
> starting with UTC time or local time.
> What would it take to optionally provide localtime to the 
> paravirtualized guests as well?
> For a guest that launches assuming localtime as its time 
> basis, then later deriving UTC from it based on configuration 
> files, this is problematic, requiring some convolutions to 
> how it handles time as it boots.
> Is there some place where we can insert a localtime offset 
> into the start-of-day structure, or perhaps change the 
> sharedinfo wallclock time to be either localtime or utc, 
> depending on a localtime parameter in the config file, 
> similar to what is done for fully virtualized guests?
I guess it might be useful to be able to configure a ''wallclock offset
in seconds'' for a domain. It would need to be implemented in Xen and
set
via a dom0 op.

Ian 

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

The paravirtualized guests are offered wallclock time referenced to UTC
only, while fully virtualized guests are given the option via the config
file (localtime parameter) of starting with UTC time or local time.
What would it take to optionally provide localtime to the
paravirtualized guests as well?
For a guest that launches assuming localtime as its time basis, then
later deriving UTC from it based on configuration files, this is
problematic, requiring some convolutions to how it handles time as it
boots.
Is there some place where we can insert a localtime offset into the
start-of-day structure, or perhaps change the sharedinfo wallclock time
to be either localtime or utc, depending on a localtime parameter in the
config file, similar to what is done for fully virtualized guests?
 
- Bruce Rogers


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

I''ll see about putting together a patch then.
Is it OK to simply have wc_sec altered by an optional, per domain time
offset from UTC in seconds (hence binary no change to the interface), or
do you think there should be another field provided that is the offset,
leaving wc_sec unmodified?
 
- Bruce Rogers
>>> "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> 3/27/2006
8:40:16 pm >>>
> The paravirtualized guests are offered wallclock time 
> referenced to UTC only, while fully virtualized guests are 
> given the option via the config file (localtime parameter) of 
> starting with UTC time or local time.
> What would it take to optionally provide localtime to the 
> paravirtualized guests as well?
> For a guest that launches assuming localtime as its time 
> basis, then later deriving UTC from it based on configuration 
> files, this is problematic, requiring some convolutions to 
> how it handles time as it boots.
> Is there some place where we can insert a localtime offset 
> into the start-of-day structure, or perhaps change the 
> sharedinfo wallclock time to be either localtime or utc, 
> depending on a localtime parameter in the config file, 
> similar to what is done for fully virtualized guests?
I guess it might be useful to be able to configure a ''wallclock offset
in seconds'' for a domain. It would need to be implemented in Xen and
set
via a dom0 op.

Ian 


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

On 28 Mar 2006, at 16:28, Bruce Rogers wrote:
> I''ll see about putting together a patch then.
> Is it OK to simply have wc_sec altered by an optional, per domain time 
> offset from UTC in seconds (hence binary no change to the interface), 
> or do you think there should be another field provided that is the 
> offset, leaving wc_sec unmodified?
The former. No need to change the guest ABI.

  -- Keir


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

This patch allows the localtime parameter to be used for
para-virtualized guests.
Some paravirtualized guests may need to start with a local time basis
instead of UTC.
This patch provides for that need.  Please review and apply.
 
Thank you
 
Signed-off-by: Bruce Rogers <brogers@novell.com>



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

On Fri, Mar 31, 2006 at 03:22:50PM -0500, Bruce Rogers wrote:
> This patch allows the localtime parameter to be used for
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis
> instead of UTC.
> This patch provides for that need.  Please review and apply.
Why is this functionality needed? what is the equivalent when running
on bare metal?

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


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

Some para-virtualized OS''s (eg. NetWare) assume they are starting from
a
localtime time base, and our start-of-day time information should allow
such a guest to work without gross modifications.  Xen already make such
an allowance for fully virtualized guests.  This is just closing the
gap.
 
- Bruce

>>> Muli Ben-Yehuda <mulix@mulix.org> 3/31/2006 1:30:47 pm
>>>
On Fri, Mar 31, 2006 at 03:22:50PM -0500, Bruce Rogers wrote:
> This patch allows the localtime parameter to be used for
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time
basis
> instead of UTC.
> This patch provides for that need.  Please review and apply.
Why is this functionality needed? what is the equivalent when running
on bare metal?

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/



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

On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> This patch allows the localtime parameter to be used for 
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis 
> instead of UTC.
> This patch provides for that need.  Please review and apply.
I''ve just checked in a patch to provide a clean wallclock update 
interface from common Xen code. Please re-send based on that patch. 
Your dom0_op implementation should modify d->time_offset_seconds 
directly and then call update_domain_wallclock_time(d).

Apart from that, the time_offset_seconds field in dom0_op.h should be 
type int32_t (we don''t use s32 in public headers).

  -- Keir


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

Thanks.  I''ll resend then.  I did notice a few issues with my original
patch, so it good that it''s getting looked at in greater detail.

- Bruce
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 4/5/2006 7:03:50 am
>>>
On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> This patch allows the localtime parameter to be used for 
> para-virtualized guests.
> Some paravirtualized guests may need to start with a local time basis
> instead of UTC.
> This patch provides for that need.  Please review and apply.
I''ve just checked in a patch to provide a clean wallclock update 
interface from common Xen code. Please re-send based on that patch. 
Your dom0_op implementation should modify d->time_offset_seconds 
directly and then call update_domain_wallclock_time(d).

Apart from that, the time_offset_seconds field in dom0_op.h should be 
type int32_t (we don''t use s32 in public headers).

  -- Keir


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

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

Attached please find a patch (against unstable tree) which provides
some localtime support for paravirtualized guests.  It is quite
minimal
in its approach, satisfying the purposes of the paravirtualized
NetWare operating system as well as any others that expect the time
base to be provided in localtime.

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.  Nevertheless,
this patch is functionaly equivalent to what is being done SLES 10''s
Xen
implementation (but with SLES10 being based on testing tree), so I felt
it
should be submitted as is, with a more comprehensive approach
submitted
separately.

Signed-off-by: Bruce Rogers <brogers@novell.com>

- Bruce
>>> On 4/5/2006 at 8:03 AM, in message
<268cbf4ac7bb43efa0994df4a124a19d@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> wrote:
> On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> 
>> This patch allows the localtime parameter to be used for 
>> para-virtualized guests.
>> Some paravirtualized guests may need to start with a local time
basis 
>> instead of UTC.
>> This patch provides for that need.  Please review and apply.
> 
> I''ve just checked in a patch to provide a clean wallclock update 
> interface from common Xen code. Please re-send based on that patch. 
> Your dom0_op implementation should modify d->time_offset_seconds 
> directly and then call update_domain_wallclock_time(d).
> 
> Apart from that, the time_offset_seconds field in dom0_op.h should be
> type int32_t (we don''t use s32 in public headers).
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel

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

Hi,

Two quick comments/questions come to mind upon seeing this patch:

- it appears possible to set/reset the time offset multiple times even while
the domain is running. Am I misreading the patch ?  Is this desirable ?

- this is a different mechanism than the one used to set time offsets for
fully virtualized guests. At the lowest levels, this is probably difficult
to avoid.  Higher up, though, it would be nice if this type of capability
didn''t look/act and be controlled differently.  The differences between
fully and para virtualized systems should disappear the higher into the
control logic you go.  Were you able to give any thought on how to merge the
models ?

-b



On 6/20/06, Bruce Rogers <BROGERS@novell.com>
wrote:
>
> Attached please find a patch (against unstable tree) which provides
> some localtime support for paravirtualized guests.  It is quite
> minimal
> in its approach, satisfying the purposes of the paravirtualized
> NetWare operating system as well as any others that expect the time
> base to be provided in localtime.
>
> 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.  Nevertheless,
> this patch is functionaly equivalent to what is being done SLES
10''s
> Xen
> implementation (but with SLES10 being based on testing tree), so I felt
> it
> should be submitted as is, with a more comprehensive approach
> submitted
> separately.
>
> Signed-off-by: Bruce Rogers <brogers@novell.com>
>
> - Bruce
>
> >>> On 4/5/2006 at 8:03 AM, in message
> <268cbf4ac7bb43efa0994df4a124a19d@cl.cam.ac.uk>, Keir Fraser
> <Keir.Fraser@cl.cam.ac.uk> wrote:
>
> > On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
> >
> >> This patch allows the localtime parameter to be used for
> >> para-virtualized guests.
> >> Some paravirtualized guests may need to start with a local time
> basis
> >> instead of UTC.
> >> This patch provides for that need.  Please review and apply.
> >
> > I''ve just checked in a patch to provide a clean wallclock
update
> > interface from common Xen code. Please re-send based on that patch.
> > Your dom0_op implementation should modify d->time_offset_seconds
> > directly and then call update_domain_wallclock_time(d).
> >
> > Apart from that, the time_offset_seconds field in dom0_op.h should be
>
> > type int32_t (we don''t use s32 in public headers).
> >
> >   -- Keir
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>
>

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

On 21 Jun 2006, at 16:29, B Thomas wrote:
> Hi,
>
>  Two quick comments/questions come to mind upon seeing this patch:
>
>  - it appears possible to set/reset the time offset multiple times 
> even while the domain is running. Am I misreading the patch ?  Is this 
> desirable ?
Yes you can. No it probably isn''t desirable, but the higher-level tools
only call the lower-level command during domain initialisation. If they 
did call it at other times, it''d be up to them to sync with running 
guests somehow.
>  - this is a different mechanism than the one used to set time offsets 
> for fully virtualized guests. At the lowest levels, this is probably 
> difficult to avoid.  Higher up, though, it would be nice if this type 
> of capability didn''t look/act and be controlled differently.  The 
> differences between fully and para virtualized systems should 
> disappear the higher into the control logic you go.  Were you able to 
> give any thought on how to merge the models ?
The ''support'' for full-virt guests is *only* a qemu patch
right now. No
tools integration at all. Integration would have to be in xend, as it 
is xend which kicks off the qemu-dm process for HVM guests. Setting the 
''timeoffset'' based on the localtime config option
wouldn''t be very
hard, and would unify that new option across PV and HVM guests. Patches 
welcome (and moving the logic to work out what the time offset should 
be from xc.c into xend itself would be nice).

  -- Keir

>  -b
>
>
>
> On 6/20/06, Bruce Rogers <BROGERS@novell.com> wrote:
>> some localtime support for paravirtualized guests.  It is quite
>> minimal
>> in its approach, satisfying the purposes of the paravirtualized
>> NetWare operating system as well as any others that expect the time
>> base to be provided in localtime.
>>
>> 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.  Nevertheless,
>> this patch is functionaly equivalent to what is being done SLES
10''s
>> Xen
>> implementation (but with SLES10 being based on testing tree), so I 
>> felt
>> it
>> should be submitted as is, with a more comprehensive approach
>> submitted
>> separately.
>>
>> Signed-off-by: Bruce Rogers < brogers@novell.com>
>>
>> - Bruce
>>
>> >>> On 4/5/2006 at 8:03 AM, in message
>> <268cbf4ac7bb43efa0994df4a124a19d@cl.cam.ac.uk >, Keir Fraser
>> <Keir.Fraser@cl.cam.ac.uk> wrote:
>>
>> > On 31 Mar 2006, at 21:22, Bruce Rogers wrote:
>> >
>> >> This patch allows the localtime parameter to be used for
>> >> para-virtualized guests.
>> >> Some paravirtualized guests may need to start with a local
time
>> basis
>> >> instead of UTC.
>> >> This patch provides for that need.  Please review and apply.
>> >
>> > I''ve just checked in a patch to provide a clean wallclock
update
>> > interface from common Xen code. Please re-send based on that
patch.
>> > Your dom0_op implementation should modify
d->time_offset_seconds
>> > directly and then call update_domain_wallclock_time(d).
>> >
>> > Apart from that, the time_offset_seconds field in dom0_op.h should
>> be
>>
>> > type int32_t (we don''t use s32 in public headers).
>> >
>> >   -- Keir
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>>  http://lists.xensource.com/xen-devel
>>
>>
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

On 21 Jun 2006, at 16:49, Keir Fraser wrote:
>>  - this is a different mechanism than the one used to set time 
>> offsets for fully virtualized guests. At the lowest levels, this is 
>> probably difficult to avoid.  Higher up, though, it would be nice if 
>> this type of capability didn''t look/act and be controlled 
>> differently.  The differences between fully and para virtualized 
>> systems should disappear the higher into the control logic you go.  
>> Were you able to give any thought on how to merge the models ?
>
> The ''support'' for full-virt guests is *only* a qemu patch
right now.
> No tools integration at all. Integration would have to be in xend, as 
> it is xend which kicks off the qemu-dm process for HVM guests. Setting 
> the ''timeoffset'' based on the localtime config option
wouldn''t be very
> hard, and would unify that new option across PV and HVM guests. 
> Patches welcome (and moving the logic to work out what the time offset 
> should be from xc.c into xend itself would be nice).
Also, RTC emulation really belongs in Xen anyway, so it''ll be possible 
to unify at the dom0_op level at that point.

  -- Keir


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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/21/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
wrote:
>
>
> On 21 Jun 2006, at 16:49, Keir Fraser wrote:
>
> >>  - this is a different mechanism than the one used to set time
> >> offsets for fully virtualized guests. At the lowest levels, this
is
> >> probably difficult to avoid. Higher up, though, it would be nice
if
> >> this type of capability didn''t look/act and be controlled
> >> differently. The differences between fully and para virtualized
> >> systems should disappear the higher into the control logic you go.
> >> Were you able to give any thought on how to merge the models ?
> >
> > The ''support'' for full-virt guests is *only* a qemu
patch right now.
> > No tools integration at all. Integration would have to be in xend, as
> > it is xend which kicks off the qemu-dm process for HVM guests. Setting
> > the ''timeoffset'' based on the localtime config
option wouldn''t be very
> > hard, and would unify that new option across PV and HVM guests.
> > Patches welcome (and moving the logic to work out what the time offset
> > should be from xc.c into xend itself would be nice).
>
> Also, RTC emulation really belongs in Xen anyway, so it''ll be
possible
> to unify at the dom0_op level at that point.
>
>   -- Keir

Yes; I agree. That would be reasonable.

-b


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

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@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

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

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@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> 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@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel