From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [XEN-3.4] pv_ops dom0 time/clock handling --solved Date: Fri, 29 May 2009 10:00:03 -0700 Message-ID: <4A201493.5020605@goop.org> References: <4A1A6B5E.3010602@dschroeder.info> <4A1CBCA1.10301@goop.org> <4A1CEDBB.10505@dschroeder.info> <4A1DA31B.5090503@goop.org> <4A1DB1E1.1050402@dschroeder.info> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A1DB1E1.1050402@dschroeder.info> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Schroeder Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.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