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

Re: [Xen-devel] Re: [BUG 1282] time jump on live migrate root cause & proposed fixes



On Thu, 07 Aug 2008 11:25:34 +0100
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:

> It does look like the code should work.

Yeah, it looks like it should.

Unfortunately it doesn't :)

> What kernel specifically have you reproduced this behaviour with?

The current RHEL 5 kernel (2.6.18-92.1.6.el5xen).

I have instrumented time_resume and am seeing something very
strange.  I have two systemtap hooks, one when entering the
function and one when returning from the function.

This output contains the trace info from two live migrates.

As you can see, time_resume() manages to get a new
system_timestamp from each host just fine, through
get_time_values_from_xen().

However, the data that update_wallclock() retrieves
from the HYPERVISOR_shared_info does not change. Even
wc_version stays the same across both host systems!

# ./time_resume.stap 
entering time_resume, secs = 1217875833, nsecs = 869795597
system_time = 237323812007279, shadow_tv_version = 350
leaving time_resume,  secs = 1217875833, nsecs = 869795597
system_time = 604085945766733, shadow_tv_version = 350
entering time_resume, secs = 1217875833, nsecs = 869795597
system_time = 604262961766733, shadow_tv_version = 350
leaving time_resume,  secs = 1217875833, nsecs = 869795597
system_time = 237501337935436, shadow_tv_version = 350

-- 
All rights reversed.

_______________________________________________
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®.