On Thu, Feb 21, 2019 at 08:38:39AM +0000, Julien Grall wrote:
> Hi Roger,
>
> On Thu, 21 Feb 2019, 08:08 Roger Pau Monn?, <[email protected]> wrote:
>
> > FWIW, you can also mask the interrupt while waiting for the thread to
> > execute the interrupt handler. Ie:
> >
>
> Thank you for providing steps, however where would the masking be done? By
> the irqchip or a custom solution?
I'm not familiar with the irqchip infrastructure in Linux, what I
proposed below is what FreeBSD does when running interrupt handlers in
deferred threads IIRC.
If irqchip has a specific handler to dispatch to a thread, then that's
the place where the masking should happen. Likely, the unmasking
should be done by the irq handling infrastructure after the thread
executing the interrupt handler has finished.
Isn't there a similar way to handle interrupts in threads for Linux?
>
> > 1. Interrupt injected
> > 2. Execute guest event channel callback
> > 3. Scan for pending interrupts
> > 4. Mask interrupt
> > 5. Clear pending field
> > 6. Queue threaded handler
> > 7. Go to 3 until all interrupts are drained
> > [...]
> > 8. Execute interrupt handler in thread
> > 9. Unmask interrupt
> >
> > That should prevent you from stacking interrupts?
> >
> > Roger.
> >
Hi Roger,
On 21/02/2019 09:14, Roger Pau Monné wrote:
> On Thu, Feb 21, 2019 at 08:38:39AM +0000, Julien Grall wrote:
>> Hi Roger,
>>
>> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, <[email protected]> wrote:
>>
>>> FWIW, you can also mask the interrupt while waiting for the thread to
>>> execute the interrupt handler. Ie:
>>>
>>
>> Thank you for providing steps, however where would the masking be done? By
>> the irqchip or a custom solution?
>
> I'm not familiar with the irqchip infrastructure in Linux, what I
> proposed below is what FreeBSD does when running interrupt handlers in
> deferred threads IIRC.
>
> If irqchip has a specific handler to dispatch to a thread, then that's
> the place where the masking should happen. Likely, the unmasking
> should be done by the irq handling infrastructure after the thread
> executing the interrupt handler has finished.
>
> Isn't there a similar way to handle interrupts in threads for Linux?
Linux has a flag (IRQF_ONESHOT) to mask interrupt until the interrupt
handler has been run. It is set for all interrupts handler that have
been forced to be threaded.
However, it looks like the flag is been ignored by the irqchip handler
we use (handle_edge_irq). Doing a bit of digging, IRQF_ONESHOT use to be
handled in handle_edge_irq until the following commit from 2009:
commit 4dbc9ca219b0f294332e734528f7b82211700170
Author: Thomas Gleixner <[email protected]>
Date: Thu Aug 27 09:38:49 2009 +0200
genirq: Do not mask oneshot edge type interrupts
Masking oneshot edge type interrupts is wrong as we might lose an
interrupt which is issued when the threaded handler is handling the
device. We can keep the irq unmasked safely as with edge type
interrupts there is no danger of interrupt floods. If the threaded
handler has not yet finished then IRQTF_RUNTHREAD is set which will
keep the handler thread active.
Debugged and verified in preempt-rt.
Signed-off-by: Thomas Gleixner <[email protected]>
Furthermore, it is pretty clear from the comment on top of
handle_edge_irq that the same interrupt can come-up before the first one
is one is handled by the associated event handler.
I am still trying to figure out whether the issue lies in the evtchn
driver or the Xen irqchip (events_base.c). I will have a closer look and
come back with updates here.
Cheers,
--
Julien Grall
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.