On 2012-05-30 16:42, Michael S. Tsirkin wrote: > On Wed, May 30, 2012 at 04:38:25PM +0200, Jan Kiszka wrote: >> On 2012-05-30 15:34, Michael S. Tsirkin wrote: >>> Below's as far as I got - hopefully this >>> explains what I had in mind: for deep hierarchies >>> this will save a bus scan so I think this makes sense >>> even in the absense of kvm irqchip. >>> >>> Warning: completely untested and known to be incomplete. >>> Please judge whether this is going in a direction that >>> is helpful for your efforts. If you respond in the positive, >>> I hope to be able to get back to this next week. >> >> We need to >> - account for polarity changes along the route >> - get rid of irq_count as it is no longer updated in the fast path, >> thus useless on routing updates > > I'll need to consider this more to understand what you mean here.
If, e.g., the host bridge is configured to flip the polarity of some interrupt on delivery, the fast path must be able to explore this in order to do the same. Then you may want to have a look at how irq_count is maintained and when it is used. > >> So it's a bit more complicated and requires a some broader refactorings. > > Is this one good as a first step then? > If not I'll drop it for now. I think we can't reliably implement this fast path delivery without solving the above issues, so we can't do it stepwise, at least not with this as first one. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
