| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [XEN-3.4] pv_ops dom0 time/clock handling
Jeremy Fitzhardinge wrote:
> Daniel Schroeder wrote:
>> Jeremy Fitzhardinge wrote:
>>
>>> Daniel Schroeder wrote:
>>>
>>>> Wed May 27 09:33:12 CEST 2009
>>>> Mi Mai 27 11:33:13 CEST 2009
>>>>
>>> That does look like some kind of TZ issue, but I'm not sure where it
>>> would be.
>>>
>>>
>>>> btw: i have checked with 32 bit pvops and 64 bit pvops dom0 and the
>>>> time
>>>> in the domU is correct with the 64bit pvops dom0 kernel...this wasnt
>>>> the same domU...so, next step for me, is to copy the domU to the 64bit
>>>> system and try again...to verify, that this only happens for me with
>>>> 32bit pvops dom0...
>>>>
>>> How odd.
>>>
>>>
>>>>> One difference between pvops time handling and the -xen kernels, is
>>>>> that
>>>>> they defaulted to slaving the domU time off the hypervisor at all
>>>>> times,
>>>>> so a system time change would propagate into guests. I don't
>>>>> implement
>>>>> that in pvops kernels, so they'll maintain independent time unless you
>>>>> explicitly sync with some mechanism like ntp.
>>>>>
>>>> hmm...does this mean, that i have to use ntp in domU if i use the pvops
>>>> kernel? Because time changes in dom0 doesnt propagate into domUs?
>>>>
>>> It will set its initial time-of-day clock from the hypervisor's at boot,
>>>
>>
>> hmm...hwclock --show on affected system:
>>
>> hwclock --show
>> Wed May 27 23:06:20 2009 -0.778274 seconds
>>
>> hwclock was set to localtime...
>>
>> on not affected system
>>
>> hwclock --show
>> Cannot access the Hardware Clock via any known method.
>> Use the --debug option to see the details of our search for an access
>> method.
>>
>> i have changed the settings in my distro from hwclock localtime to UTC,
>> reset the hwclock
>> hwclock --utc --systohc
>> rebooted
>> everything is fine now...
>
> Hm, that probably needs looking at. hwclock directly pokes the hardware
> to set the system time, which isn't very nice; there's a proper
> hypercall to do that. The fact that it has different behaviour on 32
> and 64 bit is particularly ugly...
the issue with my 64bit kernel is a missing driver, so that hwclock
cannot find the clock and cannot update it(i think, that this is a
driver/kernel option issue).So the hw clock is still in factory default
mode (utc). My specific 32bit system gets updated by my settings of my
distribution to sync the hwclock with system clock and so runs the
hwclock in localtime.
>
> Not sure what the right answer would be. From a user perspective, I
> guess making hwclock do the right thing under Xen is the answer, but I'm
> not sure how/where it is maintained.
The interesting question for me is: what is the difference between
xenified kernel and pvops kernel? Xenified Kernel had no problem with
localtime hwclock...
You wrote, that the hypervisor provides domUs with hwclock at boot
time...the hypervisor alone cannot estimate if the time it gets from the
hwclock is utc or whatever...
daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home