On Mon, Aug 13, 2012 at 02:30:49PM +0300, Avi Kivity wrote: > 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. Along with dest_id. > apicid is > unpredicatable; the others are. What do you mean "unpredicatable"? > > 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). > We can change kvm_irq_delivery_to_apic() to avoid the loop if interrupt is physical, non broadcast, non low prio. Do whatever it does now otherwise. You think we do not need cache in such case? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
