From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: RE: Saving/Restoring IA32_TSC_AUX MSR Date: Fri, 11 Dec 2009 10:20:43 -0800 Message-ID: <4B228D7B.709@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, "Dugger, Donald D" , "Xu, Dongxiao" , Keir Fraser , "Nakajima, Jun" , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org On 12/11/09 07:09, Dan Magenheimer wrote: >> As I know, RDTSCP can used to implment fast vgetcpu in >> newer Linux kernel. >> > Yes, but code which uses fast vgetcpu is expecting > to get physical cpu and physical node number. Since > an HVM guest OS only has access to virtual cpu and > virtual node number, the information written to TSC_AUX > by a guest OS is misleading and may silently break any > userland code that assumes it is getting physical > information. > It will fall back to using the segment limit trick to get vcpu+vnode info if rdtscp isn't available, so they'll get the info either way. It's not clear how many apps make good use of the numa node info, but presumably some do. So long as the virtual numa info bears some vague resemblance to the real topology then they could still make use of it in a Xen domain. Whether or not Xen currently implements that is a separate question. 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. J