WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: pvclock in userland (reprise)

To: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: pvclock in userland (reprise)
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 17 Sep 2009 20:23:14 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 17 Sep 2009 12:23:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0B53E02A2965CE4F9ADB38B34501A3A19411DC3F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco3wIEUOMEVM/j+SGeKFmFaWmbhWgACRF3UAAA5/QAAAHSniA==
Thread-topic: pvclock in userland (reprise)
User-agent: Microsoft-Entourage/12.20.0.090605
On 17/09/2009 20:13, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> wrote:

>>> A remaining hard problem is that this single
>>> "userland-accessible shared page" must be somehow
>>> made available to apps (I suggested a rdmsr emulated
>>> by Xen so that it works in userland) and must be
>>> mapped into the app address space without kernel
>>> changes.  I think someone (Keir?) suggested this
>>> problem was solveable before we got sidetracked
>>> on the need-vcpu-number-in-userland problem.
>>  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.
> 
> 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?

Yeah, that'd work. Doesn't even really need any Xen changes -- the
stable-TSC flag is in CPUID already, and the guest driver can concoct a
pvclock page I would think (e.g., from its own Xen pvclock TSC scaling
parameters).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel