| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: RE： RE: [Xen-devel] when timer go back in dom0 save and restore ormi
Keir Fraser wrote:
Might this be a pv_ops bug in newer Linux kernels? I don’t really get
what you’re describing though.
-- Keir
On 27/11/08 10:21, "James Song" <jsong@xxxxxxxxxx> wrote:
Hi,
Ok, now two machine A and B. the system-time of A is ahead of
B. So wc_sec of A is also bigger than B. When PV dom in A migrate
to B, we haven't upate that PV dom's wc_sec to equal with B. Ok,
now we see pv dom's kernel:
xen_sched_clock() in arch/86/xen/time.c
andxen_clocksource_read() arch/x86/kernel/time_32-xen.c
you will find if state_entry_time of its's vcpu, because the
state_entry_time is initalized in machine A. this time it more big
than "now" of machine B. So no schedule, no system-update in Guest os.
I don't whether did I describe it clearly.
At one point I had some code in there to work out the delta between the
system timestamps before and after save/restore, but I think I ended up
deciding it wasn't necessary because the clocksource and clockevents get
reinitialized from scratch by the core clock code on resume.
I don't understand your mention of wc_sec, since the wallclock only used
very occasionally, and never for scheduling.
If this is in relation to the Novell forward-port kernel, perhaps you
should look at what the mainline pvops xen code in this area.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home