This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] DomU clock jumps forward then freezes after Dom0 reboot

To: Cédric Schieli <cschieli@xxxxxxxxx>
Subject: Re: [Xen-devel] DomU clock jumps forward then freezes after Dom0 reboot
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 25 Oct 2010 17:21:57 -0700
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 25 Oct 2010 17:22:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTikirKrLuGX7fxEn=SWC1a_59zOZ9FgFVV8h51Vg@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTimafVSdxMGXV6MJLg-k=OwF29etBfzQyPfXt8R2@xxxxxxxxxxxxxx> <AANLkTikirKrLuGX7fxEn=SWC1a_59zOZ9FgFVV8h51Vg@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4
 On 10/24/2010 05:31 AM, Cédric Schieli wrote:
> Hello,
> I can confirm my problem reported here
> http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00057.html
> 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 to
> a host with a longer uptime will unblock the domain, but the wallclock
> will be several hours forward. Migrating back will block again.

Does this help?

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
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 <jeremy.fitzhardinge@xxxxxxxxxx>

diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.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_time_info 
 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 = 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 != &xen_vcpuop_clockevent)

Xen-devel mailing list