From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: pvclock in userland (reprise) Date: Fri, 18 Sep 2009 17:33:29 -0700 Message-ID: <4AB426D9.1080309@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)" , Donald D Dugger , Jun Nakajima , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 09/18/09 01:06, Keir Fraser wrote: > On 18/09/2009 08:29, "Jan Beulich" wrote: > > >>> I don't think mapping things into application address space is really >>> possible without guest kernel changes. The guest kernel owns and manages the >>> pte that you'd be overwriting. Just blatting the pte would not be good form. >>> >> Unless they sit in Xen's virtual space. >> > Oh yes, I remember we talked about that before. That is possible, but the > design fell down on other points. I think guest kernel involvement, even if > only as a kernel driver, should make this more tractable. > Xen's memory isn't mappable in a 32-bit compat domain, so you'd need to come up with something else there. Does Xen still claim the top part of the 32-bit address space? J