[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] how to keep time of windows pvhvm synchronized with host after resuming



At 09:51 +0100 on 22 Sep (1285149077), ANNIE LI wrote:
> > Not that I can remember.  You could try scattering printks in
> > hvm_latch_shinfo_size() to see if it's getting called at all,
> > and in arch_set_info_guest() to see if it's calling
> > update_domain_wallclock_time() like it should.
> hvm_latch_shinfo_size() is called and HVM_PARAM_CALLBACK_IRQ is sent to 
> do_hvm_op in hvm.c.
> 
> Totally, 4 functions call update_domain_wallclock_time, they are 
> rtc_set_time(), arch_set_info_guest(), construct_dom0() and 
> do_settime().The result is:
> rtc_set_time() is never called.
> construct_dom0() and arch_set_info_guest() are called once. However, 
> update_domain_wallclock_time() was not called in arch_set_info_guest() 
> since v->vcpu_id is 1 instead of 0. Is it the expected result?

I had expected arch_set_info_guest() to be called for every vcpu in the
HVM guest on restore, because boot_vcpu() is called from hvm_load_cpu_ctxt().

> do_settime() is called regularly. The call route is 
> do_platform_op()->XENPF_settime->do_settime()->update_domain_wallclock_time().
>  
> 
> Is do_settime(...) the function to update wc_sec and wc_nsec? Parameters 
> secs and nsecs are always variable. It seems wc_sec and wc_nsec are 
> calculated from secs, nsecs and system_time_base, but wc_sec keep 
> unchanged all the time. Anything else i missed?

Yes, do_settime() updates the master copy of wc_sec and wc_nsec from its
inputs, and then copies them to all domains' private copies.  So the
question is:
 - is the _master_ copy of wc_sec always zero; or
 - is the master copy right and the HVM domain's copy wrong; or
 - is the HVM domain's copy right as seen from Xen but 
   wrong as seen from the tools inside the guest?

(i.e. is wallclock broken, is propagation broken, or are the tools and
Xen using different layouts for the shared_info page?)

Cheers,

Tim.

> Thanks
> Annie

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.