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


[Xen-devel] RE: Live migration fails due to c/s 20627

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Live migration fails due to c/s 20627
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Tue, 15 Dec 2009 18:07:06 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "kurt.hackel@xxxxxxxxxx" <kurt.hackel@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
Delivery-date: Tue, 15 Dec 2009 18:07:40 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <060b8e55-bd85-4504-8c6e-c954398bd1c2@default>
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: <6CADD16F56BC954D8E28F3836FA7ED7105AC868872@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <060b8e55-bd85-4504-8c6e-c954398bd1c2@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acp9qVLJiIEieTSjQw6C1lHNEledIAABkgPg
Thread-topic: Live migration fails due to c/s 20627
Dan Magenheimer wrote on Tue, 15 Dec 2009 at 09:08:40:

> As Jeremy has pointed out, the guest OS already has
> other mechanisms to provide this information, and
> as Jun has pointed out, the non-rdtscp mechanism (lsl
> on Linux) may even be faster. Windows does not even
> provide TSC_AUX, so it definitely has other ways to
> obtain node/cpu info.  And, as I've said before,
> the node/cpu info provided by Linux in TSC_AUX is
> wrong anyway (except in very constrained environments
> such as where the admin has pinned vcpus to pcpus).

I think we should distinguish architectural support and Linux-specific issues. 
We need to enable RDSTCP support in HVM if user apps want to use it. If we want 
the Linux or other kernel to stop using TSC_AUX, we can mask off the feature in 
CPUID. Access to the MSR should result in #GP in the guest if the feature is 
not advertized. 

BTW, I'm hearing that the max TSC difference among CPUs is less than 10 cycles 
or so (virtually 0) at least Intel-based machines (except limited ones with 
known issues), so probably such pinning should not be required because vcpu 
migration should take more than.  

Intel Open Source Technology Center

Xen-devel mailing list