Re: [RFC PATCH 0/2] irq destination caching prototype

[Avi Kivity <avi@redhat.com>]

On 08/13/2012 02:12 PM, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 02:03:51PM +0300, Avi Kivity wrote:
>> On 08/13/2012 02:01 PM, Gleb Natapov wrote:
>> >> 
>> >> Actually this is overkill.  Suppose we do an apicid->vcpu translation
>> >> cache?  Then we retain O(1) behaviour, no need for a huge cache.
>> >> 
>> > Not sure I follow.
>> 
>> Unicast MSIs and IPIs can be speeded up by looking up the vcpu using the
>> apic id, using a static lookup table (only changed when the guest
>> updates apicid or a vcpu is inserted).
>> 
> To check that MSI/IPI is unicast you need to check a lot of things: delivery
> mode, shorthand, dest mode, vector. In short everything but level. This
> is exactly what kvm_irq_delivery_to_apic() is doing. Caching apicid->vcpu
> is not enough, caching (delivery mode, shorthand, dest mode,
> vector)->vcpu is enough and this is exactly what the patch does for irq
> routing entries.


apicid is checked in a loop, the others aren't.  apicid is
unpredicatable; the others are.

I think we should use apicid loopup exclusively.  It doesn't accelerate
everything, but most things, and is common to all unicast interrupts
except PIC (and we can also precompute the target vcpu for PIC, too).

-- 
error compiling committee.c: too many arguments to function