[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 08/01/2009 00:40, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote: > 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). Using alloc_xenheap_page would be okay. > 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... Yes, sounds okay. K. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |