WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Daniel Schroeder <sec@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [XEN-3.4] pv_ops dom0 time/clock handling --solved
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 29 May 2009 10:00:03 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 29 May 2009 10:00:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A1DB1E1.1050402@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C6402099.BBA0%keir.fraser@xxxxxxxxxxxxx> <4A1A6B5E.3010602@xxxxxxxxxxxxxxx> <4A1CBCA1.10301@xxxxxxxx> <4A1CEDBB.10505@xxxxxxxxxxxxxxx> <4A1DA31B.5090503@xxxxxxxx> <4A1DB1E1.1050402@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
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

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