xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Xen-devel@lists.xen.org
Subject: Re: [BUG 2.6.32.y] Broken PV migration between hosts with	different uptime, non-monotonic time?
Date: Fri, 4 May 2012 11:39:03 +0100	[thread overview]
Message-ID: <4FA3B1C7.4060201@citrix.com> (raw)
In-Reply-To: <201205041054.04079.hahn@univention.de>

On 04/05/12 09:54, Philipp Hahn wrote:
> Hello,
> 
> I encountered the following bug when migrating a Linux-2.6.32.54 PV domain on 
> Xen-3.4.3 between different hosts, whose uptime differs by several minutes (3 
> hosts, each ~5 minutes apart): When migrating from a host with lower uptime 
> to a host with higher uptime, the VM looses it's network connection for some 
> time and then continues after some minutes (roughly equivalent to the 
> difference in uptime?).
> There are two different symptoms: Either the VM becomes unpingable, or the VM 
> is pingable but the ssh-connection freezes: a while-loop dumping /proc/uptime 
> freezes and continues without a jump after the freeze is over.

Xen 3.4 doesn't ensure that the TSC is stable across migrates (Xen 4.0
does).  If the host CPU has the CONSTANT_TSC bit in the Advanced Power
Management CPUID leaf it will pass this through to the guest which makes
the guest think the TSC is stable.

Can you try this libxc patch?

8<------------------------
libxc: clear CONSTANT_TSC bit in Advanced Power Management CPUID leaf

Even if the TSC is constant on a host, it won't be constant across a
migrate.

Signed-off-by: David Vrabel <david.vrabel@citrix.com
----
 tools/libxc/xc_cpuid_x86.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff -r 884f24257f2c tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Tue Apr 17 14:47:14 2012 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Tue Apr 17 17:33:37 2012 +0100
@@ -199,6 +199,13 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_NX, regs[3]);
         break;

+    case 0x80000007: /* Advanced Power Management */
+        /*
+         * Even if the TSC is constant on a host, it won't be constant
+         * across a migrate.
+         */
+        clear_bit(X86_FEATURE_CONSTANT_TSC, regs[3]);
+        break;

     case 0x80000008:
         regs[0] &= 0x0000ffffu;
@@ -298,6 +305,13 @@ static void xc_cpuid_pv_policy(
         clear_bit(X86_FEATURE_SKINIT, regs[2]);
         clear_bit(X86_FEATURE_WDT, regs[2]);
         break;
+    case 0x80000007: /* Advanced Power Management */
+        /*
+         * Even if the TSC is constant on a host, it won't be constant
+         * across a migrate.
+         */
+        clear_bit(X86_FEATURE_CONSTANT_TSC, regs[3]);
+        break;
     case 5: /* MONITOR/MWAIT */
     case 0xa: /* Architectural Performance Monitor Features */
     case 0x8000000a: /* SVM revision and features */

  reply	other threads:[~2012-05-04 10:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04  8:54 [BUG 2.6.32.y] Broken PV migration between hosts with different uptime, non-monotonic time? Philipp Hahn
2012-05-04 10:39 ` David Vrabel [this message]
2012-05-04 13:10   ` Philipp Hahn
2012-05-04 13:20     ` David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA3B1C7.4060201@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=Xen-devel@lists.xen.org \
    --cc=hahn@univention.de \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).