From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: RE: rdtsc: correctness vs performance on Xen (and KVM?) Date: Wed, 02 Sep 2009 14:44:47 -0700 Message-ID: <4A9EE74F.1000605@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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: Keir Fraser Cc: Dan Magenheimer , "Xen-Devel (E-mail)" , Jan Beulich , Alan Cox List-Id: xen-devel@lists.xenproject.org On 09/02/09 00:20, Keir Fraser wrote: > The problem is a bit easier with vsyscall potentially. For example, give > each thread its own vsyscall clock data area (easy?), updated by kernel > whenever the thread is scheduled, and increment a version counter, checked > before and after by the vsyscall operation. > Yes. Perhaps the very simplest way would be to make the kernel update the pvclock version counter on context switch, the same way Xen does; that would allow the usermode vsyscall code to use exactly the same algorithm as the kernel code. Would Xen cope with that? > Well, I don't know how easy or fast that could actually be implemented, but > I'm at least confident it could work. But it does need kernel assistance. > Yes. I'm very uneasy about letting usermode have direct access to bits of Xen without the kernel's knowledge anyway. It suddenly means we need to not only maintain a Xen<->kernel ABI, but a Xen<->usermode ABI as well. J