Am 04.12.2010 15:41, Thomas Gleixner wrote: > 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. The worst case remains infinite (user space never signals end of interrupt). > > 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 It doesn't synchronize the tail part against the masking in the handler(s), that's driver business. > 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. Yes, I thought about this kind of transition (re-invoking the existing handler) already. We do need notification of the switch (at least for exclusive->shared) as only the driver can migrate the masking for in-flight interrupts. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
