Hi Thomas ! I noticed a problem with some powerpc systems with threaded IRQs. I hadn't looked at threaded irq in the past so there was a bit of discovery involved. That lead to a few questions:
- Threaded IRQs rely on IRQF_ONESHOT. Now, is that a flag/feature that is generally exposed to drivers even in the non-threaded case, and if yes, what core callback are drivers expected to use to "unmask" the oneshot interrupt ? - I don't see any provisions for dealing with interrupts lost while masked. So on some PICs on powerpc, while we do use "fast EOI", we also have a chance of edge interrupts (MSIs) being lost while masked. This wasn't a problem until now because we used lazy disabling. However, it looks like IRQF_ONESHOT (and thus threaded irqs) rely on masked interrupts being latched in HW, otherwise an interrupt might be lost between the threaded handler completing and the interrupt being unmasked, or am I missing something ? - I noticed that other flow handlers (edge, edge_eoi, ...) don't have any provision for IRQF_ONESHOT. Isn't that a problem ? Or will the core silently swallow subsequent interrupts until the thread has completed anyway ? (I might be missing something here). Generally, how do you suggest I fix the threaded irq problem for XICS ? (For the newer P9 XIVE interrupt controller I can probably fix things by using a different masking mechanism in HW but for the old XICS, especially with the hypervisor under the hood, I'm less confident). I'd rather not write my own flow handler, that's a recipe for missing fixes going into the generic ones and horrible bitrot... Cheers, Ben.
