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: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Wed, 16 Dec 2009 10:43:55 +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>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
Delivery-date: Tue, 15 Dec 2009 18:45:04 -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: Acp9qVG0ZjPHKCbbReaRvWQoSa0+YwAS+noQ
Thread-topic: Live migration fails due to c/s 20627
>.  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 don't agree with you at this point. For guest numa support, it should be a 
must to pin virtual node's vcpus to its related physical node and crossing-node 
vcpu migration should be disallowed by default, otherwise guest numa support is 
meaningless, right ?  
If vcpu's migration only happens in its physical node, I can't see why you 
thought the info provided in the MSR is wrong.   Actually, each vcpu should 
have a virtual TSC_AUX_MSR(guest should set it before using it), and this 
virtual MSR is saved/restored from/to physical TSC_AUX_MSR between context 
switch, so in vmx non-root mode the value in physical TSC_AUX_MSR should follow 
guest's setting rather than host's setting , and it also reflect guest's info 
related to virtual node/virtual cpu, and it still should be the expected value 
for guest's applications.  In addition, we have to know host's TSC_AUX_MSR and 
guest's TSC_AUX_MSR are totally two different things except that they are saved 
in one physical register in cpu's different execution phases, shouldn't  mix 
them together.      

Xen-devel mailing list