From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: pvclock in userland (reprise) Date: Thu, 17 Sep 2009 12:24:14 -0700 Message-ID: <4AB28CDE.4020208@goop.org> References: <0B53E02A2965CE4F9ADB38B34501A3A19411DC3F@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0B53E02A2965CE4F9ADB38B34501A3A19411DC3F@orsmsx505.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Nakajima, Jun" Cc: Dan Magenheimer , "Xen-Devel (E-mail)" , "Dugger, Donald D" , Keir Fraser , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 09/17/09 12:13, Nakajima, Jun wrote: > Maybe you can write a device driver in the guest that sets up mapping against the (virtual) physical memory, then use mmap() in the app? > Dan is trying to avoid making guest kernel changes, on the grounds that waiting for enterprise distros to catch up would take too long. Once you're making kernel changes then you can update the pvclock mechanism to use the xen clock algorithm, obviating the need for usermode ABI changes. However, if its really the case that the tsc is guaranteed synchronized, then the guest can determine that for itself by looking at cpuid and/or /proc/cpuinfo (and presumably doing some sanity checking) and then just directly use rdtsc, with no need to change either Xen or the kernel. J