From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: write_tsc in a PV domain? Date: Mon, 31 Aug 2009 12:18:39 -0700 Message-ID: <4A9C220F.3050902@goop.org> References: <25b28950-8720-4d8f-a88a-bae8ffe6e602@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <25b28950-8720-4d8f-a88a-bae8ffe6e602@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 (E-mail)" , Keir Fraser , Alan Cox List-Id: xen-devel@lists.xenproject.org On 08/31/09 11:11, Dan Magenheimer wrote: > I'm experimenting with clock_gettime(), gettimeofday(), > and rdtsc with a 2.6.30 64-bit pvguest. I have tried both > with kernel.vsyscall64 equal to 0 and 1 (but haven't seen > any significant difference between the two). I have > confirmed from sysfs that clocksource=xen > Yeah, as I said, I wouldn't expect vsyscall to work under Xen at the moment; the Xen clocksource will disable it. Clocksources can implement a "vread" method for use from a vsyscall, but from a quick look it didn't appear we could use it as-is (because the pvclock info isn't mapped into userspace, and the current vsyscall code assumes a single set of parameters rather than percpu). J