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

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

> 
> On 07/01/2009 02:59, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
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.
> 

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel