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: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Live migration fails due to c/s 20627
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 15 Dec 2009 20:14:27 -0800 (PST)
Cc: kurt.hackel@xxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
Delivery-date: Tue, 15 Dec 2009 20:15:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <EB8593BCECAB3D40A8248BE0B6400A382E874BEF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >.  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 ?

It's not a must.  A system administrator should always
have the option of choosing flexibility vs performance.
I agree that when performance is higher priority, pinning
is a must, but pinning may even have issues when the
guest's nvcpus exceeds the number of cores in a node.

So I am saying there are many cases where TSC_AUX,
when set by a guest OS, will be incorrect.  And yes I
agree there are cases (with pinning) where it will
be correct.  But how does an app or OS know whether to
trust TSC_AUX or not?  Better to have some other
method to get pcpu/pnode information that is known
to be always correct (via some method of querying the hypervisor

> 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.      

My argument is simply that if TSC_AUX cannot ALWAYS
be trusted by an application, apps will NEVER trust it.
And if apps NEVER trust it, why expose it at all?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>