[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 09:51:21 +1100
  • Cc:
  • Delivery-date: Wed, 07 Jan 2009 14:51:52 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclwbQESFc81qMn2SR2vAjv2yU5MgQABpemAAAyUQdEAAFfuQAAAdgGuAAA1Q7AAAPb/BAAAN9OgAADpQpkAA5LWcAAAj3LQABWGf/A=
  • 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).

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®.