Jürgen Keil wrote: > Stuart Maybee wrote: > >> The dom0 does not keep time for the domU's nor does it hand time to >> them. The hypervisor provides the time to all domains. It retrieves it >> from the physical hardware. > > Yep. > > @Paul Jochum: what time do you have setup in the system's BIOS > CMOS clock setup? UTC time? Or local time? > > > For Windows compatibility, I think it's easiest to use local time (not UTC) > in the system's cmos clock. > > And Solaris tries to be compatible with Windows here. > > (on dual boot boxes using local time in the cmos clock has the > disadvantage that during the switch between standard time > and daylight saving time, the cmos clock gets updated multiple > times) > > > Problem seems to be that the xen hypervisor is not compatible > with this, and expects UTC time in the PC's cmos clock. > > >> DomU's get their time from the hardware >> emulation provided by the hypervisor. > > That would be a HVM domU. > > But PV domU and dom0 can also use the time provided by the > hypervisor. > >> The only interaction dom0 has is >> that it has the capability of setting the hardware time. > >> Solaris will attempt to set the hardware time to UTC based on the >> time zone it is configured in. > > Hmm, is this correct? > > Both todpc_set() and todxen_set() try to convert UTC time to local time, > before they update the cmos hardware clock (non-xen case) > or pass the new time to the hypervisor (on xen). > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/io/todpc_subr.c#127 > > 128 static void > 129 todpc_set(tod_ops_t *top, timestruc_t ts) > 130 { > 131 todinfo_t tod = utc_to_tod(ts.tv_sec - ggmtl()); > > It adjusts by ggmt() / the gmt_lag. > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86xpv/io/xpvtod.c#117 > > 124 static void > 125 todxen_set(tod_ops_t *top, timestruc_t ts) > 126 { > 127 xen_platform_op_t op; > 128 > 129 if (DOMAIN_IS_INITDOMAIN(xen_info)) { > 130 ASSERT(MUTEX_HELD(&tod_lock)); > 131 TODOP_SET(top->tod_next, ts); > 132 > 133 op.cmd = XENPF_settime; > 134 op.interface_version = XENPF_INTERFACE_VERSION; > 135 op.u.settime.secs = ts.tv_sec - ggmtl(); > <<<<<<<<<<<<<<<<< > 136 op.u.settime.nsecs = ts.tv_nsec; > 137 op.u.settime.system_time = xpv_getsystime(); > 138 (void) HYPERVISOR_platform_op(&op); > > It adjusts UTC time by gmt_lag, on line 135. > > > The only exception would be a setup that does use UTC in the > pc's cmos clock, running Solaris with an /etc/rtc_config > setup that uses zone_info=UTC and zone_lag=0. > > > OTOH, the "struct shared_info" definition in /usr/include/xen/xen.h > tells us that the field wc_sec is supposed to store (the hypervisor boot) > time in UTC: > > /* > * Wallclock time: updated only by control software. Guests should base > * their gettimeofday() syscall on this wallclock-base value. > */ > uint32_t wc_version; /* Version counter: see vcpu_time_info_t. */ > uint32_t wc_sec; /* Secs 00:00:00 UTC, Jan 1, 1970. */ > uint32_t wc_nsec; /* Nsecs 00:00:00 UTC, Jan 1, 1970. */ > > > But with a standard SXCE installation using local time in the pc cmos clock > I do have an /etc/rtc_config with > > zone_info=Europe/Berlin > zone_lag=-7200 > > and when I look at the shared page field wc_sec, it do see local time > and not UTC time passed from the hypervisor to dom0 or domU. > And the Solaris dom0/domU kernel converts the local time to UTC > using the zone_lag from the /etc/rtc_config file. > >
You are right as usual Jurgen:-) I should have looked beyond the date command which does convert to utc and calls stime to have the kernel set the system time. Behind the scenes the kernel reconverts back to local time. And then programs the hardware. Which is the time that Xen will supply to all domains either via emulated hardware or via shared time structs to PV domains. > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > [email protected] _______________________________________________ xen-discuss mailing list [email protected]
