WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
From: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Date: Sat, 12 Dec 2009 07:44:33 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <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:44:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <aac42bb0-039b-4046-bc71-94022aed0ce8@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: <C08B02B7E75BDA4BBAA8F1648BDCC20D56F9D7F3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <aac42bb0-039b-4046-bc71-94022aed0ce8@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acp6uhdacB7VanUUSgifXlBKriK02gAAHdPw
Thread-topic: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
Dan Magenheimer wrote:
>>> 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.

Dan, 
        If later guest NUMA is implemented, both APP and 
Hypervisor/Guest are NUMA awared. APP could get benefit
>From the information of node/processor which is got from
RDTSCP. But how to implement guest NUMA is another story,
either we can use pin, or something other creative idea.

Best Regards,
-- Dongxiao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel