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: rdtsc: correctness vs performance on Xen (and KVM?)

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 1 Sep 2009 07:53:28 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 01 Sep 2009 07:54:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6C2EF6F.A26C%keir.fraser@xxxxxxxxxxxxx>
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
> >> Making vsyscall work...
> > 
> > While I highly respect your opinion, and while vsyscall
> > may be a fine choice in the future, it just doesn't
> > solve the problem today and won't solve it ever for
> > currently shipping PV OS's.  If you can figure out a
> > way to allow vsyscall to be installed as a module and
> > still achieve its performance, it
> > might be a possible solution, but otherwise we have
> > to go around the OS to solve this problem.
> 
> Do you believe there's a solution which doesn't involve PV kernel
> modifications? I think the suggestions you've made so far 
> would require such modifications.

That is certainly my goal.  I *think* the proposal
does NOT require PV OS mods as the communication
is strictly between an app and Xen.  However, I'm
really not familiar with all the subtleties of the
x86 architecture so could be missing something.
I think these are the two key architectural dependencies
that I'm not certain of:

1) fake rdmsr (or hypercall if it works) returns a virtual
   address within a range of addresses that is not "owned by"
   the OS (e.g. maybe in Xen address space?).  The page is
   only readable outside of ring 0, but writeable in ring 0
   (by Xen).
2) All TLB misses on this page are handled directly by Xen
   so the OS never sees the address/page.

If these are OK, and you see other parts of the proposal
that require PV kernel mods, please point them out.

Thanks,
Dan

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