From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: DomU clock jumps forward then freezes after Dom0 reboot Date: Tue, 26 Oct 2010 09:52:12 -0700 Message-ID: <4CC7073C.1020605@goop.org> References: <4CC61F25.80603@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?UTF-8?B?Q8OpZHJpYyBTY2hpZWxp?= Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 10/26/2010 06:08 AM, C=C3=A9dric Schieli wrote: > 2010/10/26 Jeremy Fitzhardinge : >> On 10/24/2010 05:31 AM, C=C3=A9dric Schieli wrote: >>> Hello, >>> >>> I can confirm my problem reported here >>> http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00057.h= tml >>> is the same. >>> DomU kernels affected by the migration hang are also affected by the >>> save/restore hang. Reverting "x86, paravirt: Add a global >>> synchronization point for pvclock" also fix the save/restore hang. >>> After doing save/reboot/restore (which led to a hang), migrating it t= o >>> a host with a longer uptime will unblock the domain, but the wallcloc= k >>> will be several hours forward. Migrating back will block again. >> Does this help? > Yes. With this patch applied I can migrate and migrate back without > problem. Save/restore with a reboot in between also works. OK, thanks very much. J > Thanks ! > >> From: Jeremy Fitzhardinge >> Date: Mon, 25 Oct 2010 16:53:46 -0700 >> Subject: [PATCH] x86/pvclock: zero last_value on resume >> >> If the guest domain has been suspend/resumed or migrated, then the >> system clock backing the pvclock clocksource may revert to a smaller >> value (ie, can be non-monotonic across the migration/save-restore). >> Make sure we zero last_value in that case so that the domain >> continues to see clock updates. >> >> Signed-off-by: Jeremy Fitzhardinge >> >> diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvc= lock.h >> index cd02f32..6226870 100644 >> --- a/arch/x86/include/asm/pvclock.h >> +++ b/arch/x86/include/asm/pvclock.h >> @@ -11,5 +11,6 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_ti= me_info *src); >> void pvclock_read_wallclock(struct pvclock_wall_clock *wall, >> struct pvclock_vcpu_time_info *vcpu, >> struct timespec *ts); >> +void pvclock_resume(void); >> >> #endif /* _ASM_X86_PVCLOCK_H */ >> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c >> index 239427c..a4f07c1 100644 >> --- a/arch/x86/kernel/pvclock.c >> +++ b/arch/x86/kernel/pvclock.c >> @@ -120,6 +120,11 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu= _time_info *src) >> >> static atomic64_t last_value =3D ATOMIC64_INIT(0); >> >> +void pvclock_resume(void) >> +{ >> + atomic64_set(&last_value, 0); >> +} >> + >> cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src) >> { >> struct pvclock_shadow_time shadow; >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c >> index b2bb5aa..5da5e53 100644 >> --- a/arch/x86/xen/time.c >> +++ b/arch/x86/xen/time.c >> @@ -426,6 +426,8 @@ void xen_timer_resume(void) >> { >> int cpu; >> >> + pvclock_resume(); >> + >> if (xen_clockevent !=3D &xen_vcpuop_clockevent) >> return; >> >> >> >>