From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: rdtscP and xen (and maybe the app-tsc answer I've been looking for) Date: Tue, 22 Sep 2009 12:52:41 -0700 Message-ID: <4AB92B09.8020308@goop.org> References: <60339ddd-4a9d-4efe-bd0a-bcc09bc6d468@default> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <60339ddd-4a9d-4efe-bd0a-bcc09bc6d468@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: kurt.hackel@oracle.com, "Xen-Devel (E-mail)" , Keir Fraser , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 09/22/09 12:36, Dan Magenheimer wrote: > Are you (Jeremy) still assuming that rdtsc/rdtscp are NOT > emulated? Or are you trying to define a vsyscall+pvclock > mechanism for the same constrained environments > so that HFTSAs have a choice of using clock_gettime > instead of pvrdtsc, either of which will be fast? > Yes, I'm assuming they're not emulated. If you're emulating them there's no reason to add any extra complexity to usermode by adding any other ABI: rdtsc can be rdtsc and rdtscp can be rdtscp with no Xen/ABI-imposed constraints on TSC_AUX. Once you're talking about layering another ABI onto the tsc, then there's no need to consider emulation because you can do all the necessary correction to get a canonical timestamp without it. J