On Wed, May 30, 2012 at 05:47:45PM +0200, Jan Kiszka wrote: > On 2012-05-30 16:59, Michael S. Tsirkin wrote: > > 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? > > Both belong together if we want to do it generically, IMHO.
So irq_polarity callback like we have for map_irq ATM? But at least pci bridges never do this flip. Maybe this is the property of the interrupt controller after all? > > > >> 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. > > I think what we want is to avoid any walks and intermediate state > updates for all IRQ deliveries. Well the bus is not an intermediate state ATM as piix only has a bit per IRQ so it can't OR devices together. So you want to move the counter over to piix? > That would be beneficial for any user, > not just device assignment. It would basically make the special case the > normal one, reducing code complexity. As there are still some problems > to solve for this, I'm just unsure if this step goes in the right > direction and will be reusable. > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux
