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

[Jeremy Fitzhardinge <jeremy@goop.org>]

Daniel Schroeder wrote:
>>> this works for OpenSUSE 2.6.29.X XEN dom0 Kernel...
>>> ...i have tested latest git-next repo .30-rc6 and the pv domU is two
>>> hours ahead.
>>> I have checked the following:
>>>
>>> dom0 ntpd working, correct time and /etc/localtime is correct
>>> (Europe/Berlin)
>>>
>>> domU no ntpd and correct timezone and /etc/localtime (Europe/Berlin)
>>> "localtime = 0" in pv domU config file...
>>>
>>> it seems to me, that the domU gets not UTC as basetime...
>>>       
>> This could plausibly be a pv_ops bug. I fthe only thing you change is the
>> kernel -- keeping all configuration the same -- then dom0 will be providing
>> exactly the same time info to both kernels.
>>
>>     
> checked with OpenSUSE 2.6.29.X xenified dom0...pv domU has the right
> time...booted pvops .30-rc6, pv domU gets probably localtime as
> basetime, so domU is two hours in the future...
>   

Time is pretty straightforward, and there's no TZ calculation involved 
at any points.  Its hard to see how you'd get a two hour delta (is it 
exactly 2 hours?).

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.

    J