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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Fri, 11 Dec 2009 11:29:51 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "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 11:30:14 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B229475.8060302@xxxxxxxx>
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: <744491ae-d02b-451c-817d-549ee43764a1@default> <4B229475.8060302@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acp6ktJzOemcA8kSSLeffkHh8K+dsgAAHWEQ
Thread-topic: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
Jeremy Fitzhardinge wrote on Fri, 11 Dec 2009 at 10:50:29:

> On 12/11/09 10:35, Dan Magenheimer wrote:
>>> However, the vcpu number is definitely useful to usermode
>>> apps, so they
>>> can get some idea how they're moved between (v)cpus.  I don't
>>> think it
>>> will matter to them that it isn't pcpu.
>> My point is that an app running on native Linux can
>> safely assume that, if TSC_AUX==3 at time T1 and
>> TSC_AUX is still 3 at time T2,it is running
>> on the same processor and the same node at both T1
>> and T2.  In a virtual environment it cannot even
>> assume it is running on the same machine.
>> Further if the app sees that TSC_AUX==2 at time T3
>> and TSC_AUX==3 at time T4, on native Linux it
>> can safely assume that it is running on a different
>> processor.  While rarer, in a virtual environment,
>> this may also be a false assumption.
>> That's why I say the information is misleading.
>  Sure, but that info is, at best, of heuristic value, and won't cause
> any correctness problems if it is wrong.  The performance may suck, but
> that's part of the larger problem of running NUMA-aware code in a
> virtual environment.
And to utilize various NUMA optimizations in the kernel/apps in the guest, we 
need "the virtual numa info bears some vague resemblance to the real topology" 
(from Jeremy's email) with the vcpus bound to the CPU/node.

I understand that enabling RDTSCP in HVM will disable the pvrdtscp algorithm if 
used by the kernel. One way is to mask off the feature in CPUID (by default). 
Then kernel won't use it. 

Intel Open Source Technology Center

Xen-devel mailing list

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