Re: [XEN-3.4] pv_ops dom0 time/clock handling --solved

[Jeremy Fitzhardinge <jeremy@goop.org>]

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

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.

    J