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

RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Thu, 8 Jan 2009 11:40:17 +1100
Cc:
Delivery-date: Wed, 07 Jan 2009 16:41:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D0155025A@trantor>
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: <AEC6C66638C05B468B556EA548C1A77D0155024B@trantor><C58A4F78.1422%keir.fraser@xxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0155025A@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclwbQESFc81qMn2SR2vAjv2yU5MgQABpemAAAyUQdEAAFfuQAAAdgGuAAA1Q7AAAPb/BAAAN9OgAADpQpkAA5LWcAAAj3LQABWGf/AAA+R78A==
Thread-topic: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> 
> Looking through vlapic.c some more, the vlapic regs are stored on a
> discrete page which lends itself to mapping into a DomU as has been
> suggested previously.
> 
> I think I could do this based on imitating what
XENMAPSPACE_shared_info
> does and create a new hypercall to map each vcpu's vlapic regs to an
mfn
> given by the DomU, probably on a cpu by cpu basis. Then I would patch
> windows to read and write tpr from this new space instead of the real
> vlapic mmio space, and based on the tpr threshold (as per your
previous
> email) do a VMEXIT only when necessary.
> 
> Should this be a new hypercall, or could I add a new XENMAPSPACE_
> function to the existing XENMEM_add_to_physmap hypercall (eg am I
> allowed to add HVM related code here from a design point of view).
> 

I just quickly implemented this as a 'proof of concept' by adding a
XENMAPSPACE_vlapic_regs function to XENMEM_add_to_physmap, and it works,
but only after I removed regs_page from the vlapic struct and used
alloc_xenheap_page instead of alloc_domheap_page and then
share_xen_page_with_guest. Can I do it with alloc_domheap_page? It
didn't 'just work' when I did it that way... (and I had to comment out
the use of regs_page in the vmx code to get it to compile, so as it
stands it probably wouldn't work on Intel).

Anyway, in my xp guest when I KeRaiseIrql and then read the mapped
vlapic->regs from xp I see that the TPR register is changing, so things
are looking good.

Next will be to patch windows to:
. On read, just read from the mapped space instead of the mmio space for
at least the TPR register, and maybe others if there are potential
performance gains
. On write, write the value to the mapped space, then check if an
interrupt could be pending (as per Keirs algorithm in a previous email),
and if so, write to the mmio space to force a VMEXIT (or use some other
way of invoking a VMEXIT if it's faster...). By doing the mapped write
first before checking for pending interrupts I should avoid any races...

James


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

<Prev in Thread] Current Thread [Next in Thread>