For anyone who is interested, I have implemented TPR write optimization based on Travis Betak''s amdvopt driver. My implementation gets the base address and length of hal.dll when loaded into memory and scans that for patchable instructions, instead of the patch table approach that Travis used. A preliminary test under XP shows a 10x increase in iperf performance. I''ll test under 2003sp1 soon, unfortunately my sp1 decided to automatically install sp2 and I ''xm destroy''d it in the middle of that and now it''s doing a chkdsk... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 02:59 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> > For anyone who is interested, I have implemented TPR writeoptimization> based on Travis Betak''s amdvopt driver. My implementation gets thebase> address and length of hal.dll when loaded into memory and scans thatfor> patchable instructions, instead of the patch table approach thatTravis> used. > > A preliminary test under XP shows a 10x increase in iperf performance. > > I''ll test under 2003sp1 soon, unfortunately my sp1 decided to > automatically install sp2 and I ''xm destroy''d it in the middle of that > and now it''s doing a chkdsk... >2003sp1 iperf throughput went from 150mbit/second without the patch to 950mbit/second with the patch Surprisingly, the AMD TPR write patch under 2003sp2 increases iperf throughput from 1Gbit/second (without the patch) to 1.5Gbit/second (patched). I guess this makes sense - 2003sp2 includes ''lazy write'', but the AMD patch optimises the write operation itself. Is there such a facility available under Intel CPU''s, other than the latest ''flex priority'' stuff which I am about to read up on? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-07 08:57 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 07/01/2009 02:59, "James Harper" <james.harper@bendigoit.com.au> wrote:> Is there such a facility available under Intel CPU''s, other than the > latest ''flex priority'' stuff which I am about to read up on?The LOCK MOV CR0 trick doesn''t work on Intel CPUs. You should have space to patch in a JMP instruction though, and then you can shadow the TPR value and only do actual writes when the value changes. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 09:14 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> > On 07/01/2009 02:59, "James Harper" <james.harper@bendigoit.com.au>wrote:> > > Is there such a facility available under Intel CPU''s, other than the > > latest ''flex priority'' stuff which I am about to read up on? > > The LOCK MOV CR0 trick doesn''t work on Intel CPUs. You should havespace> to patch in a JMP instruction though, and then you can shadow the TPR > value and only do actual writes when the value changes. >Travis said that the testing he did showed that the value changed every write. The ''lazy'' bit works by only writing when it actually makes a difference (eg don''t write TPR until there is an actual interrupt pending I think). It''s (probably much) less efficient for the case when a lower priority interrupt interrupts what should be a higher priority interrupt (but isn''t, because we haven''t written TPR yet), but is much more efficient for the most common case where it doesn''t get interrupted. That''s quite a bit more complicated than ''if new_tpr =old_tpr then write else nop''... I''m trying to get xentrace working to get visibility to the TPR writes so I can see for myself, but I don''t think I am seeing what I want to see. Any suggestions on that? (see previous email with an incorrect subject of ''xentrace and MSR_READ/MSR_WRITE'') How does flex priority work - does it require any work on the DomU side, or does it ''just work''? Does the VMExit caused by writing the TPR amount to the same sort of overhead as a hypercall? (eg replacing TPR writes with hypercalls is not going to make any difference is it?) James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-07 09:20 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 07/01/2009 09:14, "James Harper" <james.harper@bendigoit.com.au> wrote:> Travis said that the testing he did showed that the value changed every > write. The ''lazy'' bit works by only writing when it actually makes a > difference (eg don''t write TPR until there is an actual interrupt > pending I think). It''s (probably much) less efficient for the case when > a lower priority interrupt interrupts what should be a higher priority > interrupt (but isn''t, because we haven''t written TPR yet), but is much > more efficient for the most common case where it doesn''t get > interrupted. That''s quite a bit more complicated than ''if new_tpr => old_tpr then write else nop''...Hmmm, you could be right. I suppose xentrace can confirm one way or the other once you have it set up...> I''m trying to get xentrace working to get visibility to the TPR writes > so I can see for myself, but I don''t think I am seeing what I want to > see. Any suggestions on that? (see previous email with an incorrect > subject of ''xentrace and MSR_READ/MSR_WRITE'')George Dunlap should be able to advise.> How does flex priority work - does it require any work on the DomU side, > or does it ''just work''?It''s completely transparent and just works.> Does the VMExit caused by writing the TPR amount to the same sort of > overhead as a hypercall? (eg replacing TPR writes with hypercalls is not > going to make any difference is it?)Very little. As you say, avoiding the VMEXITs entirely is the key. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 09:33 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> On 07/01/2009 09:14, "James Harper" <james.harper@bendigoit.com.au>wrote:> > > Travis said that the testing he did showed that the value changedevery> > write. The ''lazy'' bit works by only writing when it actually makes a > > difference (eg don''t write TPR until there is an actual interrupt > > pending I think). It''s (probably much) less efficient for the casewhen> > a lower priority interrupt interrupts what should be a higherpriority> > interrupt (but isn''t, because we haven''t written TPR yet), but ismuch> > more efficient for the most common case where it doesn''t get > > interrupted. That''s quite a bit more complicated than ''if new_tpr => > old_tpr then write else nop''... > > Hmmm, you could be right. I suppose xentrace can confirm one way orthe> other once you have it set up... >I am probably showing a lack of understanding about how the APIC works here, but from a very brief look at what writing to the TPR register does, all I can see is that it sets a value in vlapic->regs->data. Could I just map a page from the DomU into xen and assign a byte in there as the TPR register (one byte per CPU). I would need a new hypercall to turn this on but that''s no big deal. Or is there more to a TPR write than just setting vlapic->regs->data? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-07 09:53 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 07/01/2009 09:33, "James Harper" <james.harper@bendigoit.com.au> wrote:>> Hmmm, you could be right. I suppose xentrace can confirm one way or > the >> other once you have it set up... >> > > I am probably showing a lack of understanding about how the APIC works > here, but from a very brief look at what writing to the TPR register > does, all I can see is that it sets a value in vlapic->regs->data. Could > I just map a page from the DomU into xen and assign a byte in there as > the TPR register (one byte per CPU). I would need a new hypercall to > turn this on but that''s no big deal. Or is there more to a TPR write > than just setting vlapic->regs->data?Sometimes it triggers an interrupt to be delivered. So you''d need a TPR threshold too to cause a VMEXIT sometimes. Or perhaps map the whole APIC page and work it out yourself (possibly the Citrix drivers do this, but I''m not really familiar with them). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 10:05 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> > I am probably showing a lack of understanding about how the APICworks> > here, but from a very brief look at what writing to the TPR register > > does, all I can see is that it sets a value in vlapic->regs->data.Could> > I just map a page from the DomU into xen and assign a byte in thereas> > the TPR register (one byte per CPU). I would need a new hypercall to > > turn this on but that''s no big deal. Or is there more to a TPR write > > than just setting vlapic->regs->data? > > Sometimes it triggers an interrupt to be delivered. So you''d need aTPR> threshold too to cause a VMEXIT sometimes. Or perhaps map the wholeAPIC> page and work it out yourself (possibly the Citrix drivers do this,but> I''m not really familiar with them).I can''t see anything that would trigger an interrupt beyond vlapic_write(). Is it just the act of invoking a VMEXIT that triggers the interrupt delivery?>From memory, there is a register somewhere that says what the highestinterrupt level that is currently blocked is... I''ll look at that. This doesn''t actually sound that hard... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-07 10:26 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 07/01/2009 10:05, "James Harper" <james.harper@bendigoit.com.au> wrote:>> Sometimes it triggers an interrupt to be delivered. So you''d need a > TPR >> threshold too to cause a VMEXIT sometimes. Or perhaps map the whole > APIC >> page and work it out yourself (possibly the Citrix drivers do this, > but >> I''m not really familiar with them). > > I can''t see anything that would trigger an interrupt beyond > vlapic_write(). Is it just the act of invoking a VMEXIT that triggers > the interrupt delivery?Yes. See vmx_intr_assist().> From memory, there is a register somewhere that says what the highest > interrupt level that is currently blocked is... I''ll look at that. This > doesn''t actually sound that hard...An interrupt is delivered if: highest_prio(IRR) > max(highest_prio(ISR), TPR). Where highest_prio() is based on a backwards bitmap scan. If you go down the route of setting a TPR threshold for vmexit, that would be (hp = highest_prio): TPR_thresh = ((hp(IRR) > hp(ISR)) && (hp(IRR) < TPR)) ? hp(IRR) : 0 Where VMEXIT occurs if TPR is updated to a value less than the threshold. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 12:12 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> On 07/01/2009 10:05, "James Harper" <james.harper@bendigoit.com.au>wrote:> > >> Sometimes it triggers an interrupt to be delivered. So you''d need a > > TPR > >> threshold too to cause a VMEXIT sometimes. Or perhaps map the whole > > APIC > >> page and work it out yourself (possibly the Citrix drivers do this, > > but > >> I''m not really familiar with them). > > > > I can''t see anything that would trigger an interrupt beyond > > vlapic_write(). Is it just the act of invoking a VMEXIT thattriggers> > the interrupt delivery? > > Yes. See vmx_intr_assist().I can see the vmx_intr_assist function, but I can''t find what calls it. Is vmx code for both amd and intel? Or is it vmx=intel and svm=amd? I''ve never got my head around those terms...> > From memory, there is a register somewhere that says what thehighest> > interrupt level that is currently blocked is... I''ll look at that.This> > doesn''t actually sound that hard... > > An interrupt is delivered if: > highest_prio(IRR) > max(highest_prio(ISR), TPR). > > Where highest_prio() is based on a backwards bitmap scan. > > If you go down the route of setting a TPR threshold for vmexit, thatwould> be (hp = highest_prio): > TPR_thresh = ((hp(IRR) > hp(ISR)) && (hp(IRR) < TPR)) ? hp(IRR) : 0 > > Where VMEXIT occurs if TPR is updated to a value less than thethreshold.>Hmmm... if I do things in the right order I should be able to avoid races. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 12:15 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> > > > Yes. See vmx_intr_assist(). > > I can see the vmx_intr_assist function, but I can''t find what callsit.>Disregard. I wasn''t grepping .S files :) James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-07 12:24 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 07/01/2009 12:12, "James Harper" <james.harper@bendigoit.com.au> wrote:>> Yes. See vmx_intr_assist(). > > I can see the vmx_intr_assist function, but I can''t find what calls it. > > Is vmx code for both amd and intel? Or is it vmx=intel and svm=amd? I''ve > never got my head around those terms...svm=amd, vmx=intel. There''s a svm_intr_assist() too. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 12:35 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> > From memory, there is a register somewhere that says what thehighest> > interrupt level that is currently blocked is... I''ll look at that.This> > doesn''t actually sound that hard... > > An interrupt is delivered if: > highest_prio(IRR) > max(highest_prio(ISR), TPR). > > Where highest_prio() is based on a backwards bitmap scan. > > If you go down the route of setting a TPR threshold for vmexit, thatwould> be (hp = highest_prio): > TPR_thresh = ((hp(IRR) > hp(ISR)) && (hp(IRR) < TPR)) ? hp(IRR) : 0 > > Where VMEXIT occurs if TPR is updated to a value less than thethreshold.>I really need to get xentrace working... if there are lots of reads and writes to the IRR and ISR registers that all involve VMEXIT''s then it may well be worth mapping the entire APIC register range into the DomU''s memory space (somehow). Otherwise I can make sure that each write to IRR and ISR (by xen or domU) gets echo''s into DomU''s memory in such a form that I can calculate the value of TPR_thresh that you have given above in my kernel patch and VMEXIT when necessary from there... I think I should figure out why xentrace isn''t telling me what I want to know as there are too many conditionals at the moment to know what the right solution is... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-07 22:51 UTC
RE: [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@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-08 00:40 UTC
RE: [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 whatXENMAPSPACE_shared_info> does and create a new hypercall to map each vcpu''s vlapic regs to anmfn> 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 yourprevious> 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@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-08 03:53 UTC
RE: [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 wouldpatch> > windows to read and write tpr from this new space instead of thereal> > 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 itworks,> 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, sothings> are looking good. > > Next will be to patch windows to: > . On read, just read from the mapped space instead of the mmio spacefor> 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 previousemail),> and if so, write to the mmio space to force a VMEXIT (or use someother> way of invoking a VMEXIT if it''s faster...). By doing the mapped write > first before checking for pending interrupts I should avoid anyraces...>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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-08 09:07 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 08/01/2009 00:40, "James Harper" <james.harper@bendigoit.com.au> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-08 09:08 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 08/01/2009 03:53, "James Harper" <james.harper@bendigoit.com.au> wrote:> 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?No.> Does disabling interrupts via cli cause a VMEXIT?No. K. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-08 09:09 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> On 08/01/2009 00:40, "James Harper" <james.harper@bendigoit.com.au>wrote:> > > I just quickly implemented this as a ''proof of concept'' by adding a > > XENMAPSPACE_vlapic_regs function to XENMEM_add_to_physmap, and itworks,> > 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 commentout> > 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.Is it possible to map a page allocated with alloc_domheap_page into the domain? The semantics must be different as it didn''t work the way I expected it to... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-08 09:10 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> On 08/01/2009 03:53, "James Harper" <james.harper@bendigoit.com.au>wrote:> > > One (big?) hiccup... how do I make sure that I am accessing thevlapic> > structure for the correct CPU? My current idea ofvlapic[current_cpu] is> > flawed because a thread switch could occur between getting theaddress> > of the vlapic structure for the current cpu and writing a value tothe> > mapped register. > > > > Is it possible to have per-cpu mapping? > > No. > > > Does disabling interrupts via cli cause a VMEXIT? > > No. >Hmmm... so I could use CLI to disable interrupts to ensure that I''ll remain on the same CPU. This idea isn''t totally sunk then... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-08 09:12 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 08/01/2009 09:09, "James Harper" <james.harper@bendigoit.com.au> wrote:>> Using alloc_xenheap_page would be okay. > > Is it possible to map a page allocated with alloc_domheap_page into the > domain? The semantics must be different as it didn''t work the way I > expected it to...It wouldn''t be easy. Just use alloc_xenheap_page(). You can get rid of the map_domain_page_global() then, too. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-08 09:14 UTC
Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)
On 08/01/2009 09:09, "James Harper" <james.harper@bendigoit.com.au> wrote:>> Using alloc_xenheap_page would be okay. > > Is it possible to map a page allocated with alloc_domheap_page into the > domain? The semantics must be different as it didn''t work the way I > expected it to...OTOH I think Intel''s FlexPriority depends on us using alloc_domheap_pages(), so we may have an issue both ways round here. The other issue with giving the guest write access to the APIC page is whether Xen can deal with random crap being written over it. Might need to audit vlapic.c for that. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-08 09:14 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> On 08/01/2009 09:09, "James Harper" <james.harper@bendigoit.com.au>wrote:> > >> Using alloc_xenheap_page would be okay. > > > > Is it possible to map a page allocated with alloc_domheap_page intothe> > domain? The semantics must be different as it didn''t work the way I > > expected it to... > > It wouldn''t be easy. Just use alloc_xenheap_page(). You can get rid ofthe> map_domain_page_global() then, too. >Okay. I might need assistance with changing the vmx use of the vlapic page as it now needs to use xenheap semantics instead of domheap semantics. I''ll try and work it out myself first though. Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2009-Jan-08 09:17 UTC
RE: [Xen-devel] TPR write optimization (even improves 2003 sp2)
> On 08/01/2009 09:09, "James Harper" <james.harper@bendigoit.com.au>wrote:> > >> Using alloc_xenheap_page would be okay. > > > > Is it possible to map a page allocated with alloc_domheap_page intothe> > domain? The semantics must be different as it didn''t work the way I > > expected it to... > > OTOH I think Intel''s FlexPriority depends on us using > alloc_domheap_pages(), > so we may have an issue both ways round here.I was afraid of that - I guess that''s where the vmx side of things uses the regs_page.> The other issue with giving > the guest write access to the APIC page is whether Xen can deal with > random > crap being written over it. Might need to audit vlapic.c for that.Are you concerned about an errant (or malicious) DomU crashing the vlapic code (and therefore Xen)? That was something I hadn''t thought of... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel