From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [XEN-3.4] pv_ops dom0 time/clock handling
Date: Tue, 26 May 2009 21:08:01 -0700
Message-ID: <4A1CBCA1.10301@goop.org>
References: <C6402099.BBA0%keir.fraser@eu.citrix.com>
	<4A1A6B5E.3010602@dschroeder.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <4A1A6B5E.3010602@dschroeder.info>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Daniel Schroeder <sec@dschroeder.info>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir.fraser@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.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