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.
 
 
This message posted from opensolaris.org
_______________________________________________
xen-discuss mailing list
[email protected]

Reply via email to