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

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

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

One (big?) hiccup... how do I make sure that I am accessing the vlapic
structure for the correct CPU? My current idea of vlapic[current_cpu] is
flawed because a thread switch could occur between getting the address
of the vlapic structure for the current cpu and writing a value to the
mapped register.

Is it possible to have per-cpu mapping?

Does disabling interrupts via cli cause a VMEXIT?

James


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