From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: =?UTF-8?B?UkXvvJogUkU6IFtYZW4tZGV2ZWxdIHdoZW4gdGltZXIgZ28gYmE=?=
	=?UTF-8?B?Y2sgaW4gZG9tMCBzYXZlIGFuZCByZXN0b3JlIG9ybWlncmF0ZSwgUFYgZG9tYWk=?=
	=?UTF-8?B?biBodW5n?=
Date: Thu, 27 Nov 2008 09:51:56 -0800
Message-ID: <492EDE3C.1020800@goop.org>
References: <C5542C34.1F9F7%keir.fraser@eu.citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <C5542C34.1F9F7%keir.fraser@eu.citrix.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: kevin.tian@intel.com, xen-devel@lists.xensource.com, James Song <jsong@novell.com>
List-Id: xen-devel@lists.xenproject.org

Keir Fraser wrote:
> Might this be a pv_ops bug in newer Linux kernels? I don=E2=80=99t real=
ly get=20
> what you=E2=80=99re 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=20
system timestamps before and after save/restore, but I think I ended up=20
deciding it wasn't necessary because the clocksource and clockevents get=20
reinitialized from scratch by the core clock code on resume.

I don't understand your mention of wc_sec, since the wallclock only used=20
very occasionally, and never for scheduling.

If this is in relation to the Novell forward-port kernel, perhaps you=20
should look at what the mainline pvops xen code in this area.

    J