[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.