Re: RE： RE: [Xen-devel] when timer go back in dom0 save and restore ormigrate, PV domain hung

[Jeremy Fitzhardinge <jeremy@goop.org>]

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@novell.com> 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