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


RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR

To: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 11 Dec 2009 15:30:40 -0800 (PST)
Cc: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Fri, 11 Dec 2009 15:31:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C08B02B7E75BDA4BBAA8F1648BDCC20D56F9D7F3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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
> > If this is true the only safe use of TSC_AUX is for
> > its originally designed intent: To determine if two
> > successive rdtscp instructions were or were not
> > executed on the same processor.  Since this cannot
> > be guaranteed in a VM, that's a reasonable argument
> > that TSC_AUX shouldn't be exposed at all (meaning the
> > rdtscp bit in cpuid should be turned off by Xen).
> This should work if you bind (i.e. pin) each vcpu to each 
> CPU, as I suggested.

Yes, it does.  If there were a reasonable way for an
application to check "am I running on a VM for which
each vcpu has been pinned?" this might be a reasonable
constraint as, if the app isn't, it could fail or at least
log a message.  But if the app will randomly fail
(or perform horribly) depending on whether the
underlying VM is pinned or not (which might even
change across a migration or if a sysadmin is
"tuning" his data center), I don't think
enterprise customers would appreciate that.

Xen-devel mailing list