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>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Live migration fails due to c/s 20627
From: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Date: Wed, 16 Dec 2009 02:04:43 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "kurt.hackel@xxxxxxxxxx" <kurt.hackel@xxxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Tue, 15 Dec 2009 10:04:59 -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: Acp9qVBM1UNl32WeQSunoeTcjo++oAABp0nQ
Thread-topic: Live migration fails due to c/s 20627
Dan Magenheimer wrote:
> Oops, forgot to reply to this part of your message.
>>> There are many cases where rdtsc/rdtscp instructions
>>> are emulated and so most of the code is already there.
>>> You only need to intercept illegal instruction traps,
>>> so there is not a significant performance issue.
>>> And the code to do the emulation is necessary
>>> to implement the pvrdtscp algorithm on hvm anyway
>> I think in HVM environment, we should respect the native
>> behavior.
> I'm not sure why you think that.  There are many many
> native silicon features that are not exposed directly
> to the guest OS.  The whole point of virtualization
> is to present an abstract hardware interface so that
> multiple VMs can be supported on a single machine and
> VMs can be moved between underlying hardware implementations.
> Breaking that flexibility for a rarely utilized instruction
> such as rdtscp seems like a very bad idea.

I didn't break the flexibility, as stated before, my next patch
will move the code for guest cpuid presentation, and then 
Administrator could mask the bit for migration. It is not only
Rdtscp has this problem.

>> Moreover, it would be valuable for
>> guest if it could get the node/cpu info which reflects
>> hardware topology.
> 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).

After guest numa is implemented, it is not a constrained
environment. Guest will benefit from the information such as
Implementing fast vgetcpu() and so on...

Best Regards,
-- Dongxiao
Xen-devel mailing list