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

Re: [Xen-devel] [hybrid]: hang in update_wall_time



On Tue, 20 Mar 2012, Mukesh Rathor wrote:
> Hi Ian/Stefano:
> 
> I changed over to the PV clock for hybrid liked we talked at the
> hackathon. I still have the hang in update_wall_time() after dom0
> switches to xen as clocksource.
> 
> The source of hang seems to be in xen stime_local_stamp in cpu_time that
> suddenly jumps to a large 64bit value. I've been chasing to figure
> where that happens, and why for the hybrid and not PV. It appears the
> source of jump is time_calibration_std_rendezvous()  in 
> c->stime_master_stamp. Chasing that, seems to come from 
> read_platform_stime(). The jump happens after switch to
> xen clocksource in dom0.
> 
> I'll continue to debug, but let me know if you have any thoughts or
> idea what might be going on.

stime_local_stamp is set to get_s_time() and get_s_time scales the tsc
value according to local_tsc_stamp and tsc_scale. You need to make sure
that these two parameters are correct for dom0 hybrid as well.

Also I would keep an eye on arch.hvm_vcpu.stime_offset and
arch.hvm_vcpu.cache_tsc_offset that only play a role in hvm domains.
Maybe they are not set to correct values in your case?

Give a look at hvm_set_guest_tsc and hvm_set_guest_time. You probably
need to initialize them on hybrid as well and make sure you take the
is_hvm_domain path in __update_vcpu_system_time.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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