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: "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 09:08:40 -0800 (PST)
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, 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 09:09:21 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6CADD16F56BC954D8E28F3836FA7ED7105AC868872@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
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.

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

Xen-devel mailing list