On Wed, May 30, 2012 at 04:46:14PM +0200, Jan Kiszka wrote: > 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.
This can be solved incrementally I think - handle polarity change like mapping change, no? > Then you may want to have a look at how irq_count is maintained and when > it is used. In my patch it simply there to OR irq levels of all devices connected to a specific pin. > > > >> 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