Jan, On Sat, 4 Dec 2010, Jan Kiszka wrote: > Am 04.12.2010 11:37, Thomas Gleixner wrote: > > On Sat, 4 Dec 2010, Jan Kiszka wrote: > > If interrupt is shared, then you want to keep the current behaviour: > > > > disable at line level (IRQF_ONESHOT) > > run handler thread (PCI level masking) > > reenable at line level in irq_finalize_oneshot() > > reenable at PCI level when guest is done > > If the interrupt is shared, we must mask at PCI level inside the primary > handler as we also have to support non-threaded users of the same line. > So we always have a transition line-level -> device-level > masking in a primary handler. Sorry that left out the hard irq part. Of course it needs to do the PCI level masking in the primary one. > reduce the latency. So both threaded and non-threaded cases should be > addressable by any approach. The oneshot magic should work on non threaded cases as well. Needs some modifications, but nothing complex. > > If interrupts are in flight accross request/free then this change > > takes effect when the next interrupt comes in. > > For registration, that might be too late. We need to synchronize on > in-flight interrupts for that line and then ensure that it gets enabled > independently of the registered user. That user may have applied > outdated information, thus would block the line for too long if user > space decides to do something else. No, that's really just a corner case when going from one to two handlers and I don't think it matters much. If you setup a new driver it's not really important whether that first thing comes in a few ms later. Also there is a pretty simple solution for this: The core code knows, that there is an ONESHOT interrupt in flight, so it simply can call the primary handler of that device with the appropriate flag set (maybe an additional one to indicate the transition) and let that deal with it. Needs some thought vs. locking and races, but that shouldn't be hard. > Pulling the effect of disable_irq_nosync into genirq also for threaded > handling would remove the need for re-registering handlers. That's good. > But we need to think about the hand-over scenarios again. Maybe > solvable, but non-trivial. See above. Thanks, tglx -- 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
