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>, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Subject: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 01 Sep 2009 16:32:51 +0100
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 01 Sep 2009 08:33:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <382878d4-f980-45e7-ab49-694344386c42@default>
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>
References: <C6C2F785.A3E6%keir.fraser@xxxxxxxxxxxxx> <382878d4-f980-45e7-ab49-694344386c42@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 01.09.09 17:26 >>>
>> On 01/09/2009 15:53, "Dan Magenheimer" 
>> <dan.magenheimer@xxxxxxxxxx> wrote:
>> 
>> > 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.
>> 
>> I think these are probably possible, at least for a 64-bit 
>> hypervisor which
>> isn't playing segment limit tricks.
>
>Will it work for pv32_on_64?  (I don't care much about
>32-bit hypervisor.)

It can be made work - you just need to properly arrange this and the
compatibility p2m table.
 
>> > If these are OK, and you see other parts of the proposal
>> > that require PV kernel mods, please point them out.
>> 
>> Won't the pvclock computation be per-cpu? How will you deal with
>> that?
>
>Hmmm... is it possible for the same virtual address/page
>to map to a different physical address/page on each processor?

Not within today's Xen or Linux (which both assume a global kernel
address space, in particular non-root page table entries mapping kernel
space to be the same in all address spaces - you'd need separate entries
at all levels for this).

Jan


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