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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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