Re: [Xen-devel] xen/evtchn and forced threaded irq

[Julien Grall]

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Ã, <roger.pau@xxxxxxxxxx> 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 <tglx@xxxxxxxxxxxxx>
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 <tglx@xxxxxxxxxxxxx>

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.