From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: RE: Saving/Restoring IA32_TSC_AUX MSR Date: Sun, 13 Dec 2009 10:59:09 -0800 Message-ID: <4B25397D.6010907@goop.org> References: <7cecbafe-f4d4-410f-a3c0-6972c102e6c2@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7cecbafe-f4d4-410f-a3c0-6972c102e6c2@default> 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/13/09 10:06, Dan Magenheimer wrote: > I agree there are some cases where the TSC_AUX value > set by a guest OS may be useful. But ensuring that its > is always useful (NEVER incorrect) requires too many restrictions, > such as pinning. > At least with respect to Linux guests [*], this objection to rdtscp is moot, because if it isn't present then Linux will fall back to another mechanism which is always present. Guest usermode will get the same info, good/bad/misleading/whatever, either way; rdtscp can't make it worse. The only question is whether specifically adding rdtscp/TSC_AUX support adds any overall improvement. (* I don't know if any other rdtscp-users attempt to put NUMA or other physical topology info into TSC_AUX. If they just stick to setting/using the cpu number, then they will get a net win from rdtscp.) J