LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Walleij <linus.walleij@linaro.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: linux-tip-commits@vger.kernel.org,
	Hans de Goede <hdegoede@redhat.com>, x86 <x86@kernel.org>
Subject: Re: [tip: irq/core] x86: Select HARDIRQS_SW_RESEND on x86
Date: Thu, 12 Mar 2020 16:55:29 +0100	[thread overview]
Message-ID: <87mu8lin4e.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CACRpkdYPy93bDwPe1wHhcwpgN9uXepKXS1Ca5yFmDVks=r0RoQ@mail.gmail.com>

Linus Walleij <linus.walleij@linaro.org> writes:
> On Wed, Mar 11, 2020 at 10:42 PM tip-bot2 for Hans de Goede
> Just help me understand the semantics of this thing...
>
> According to the text in KConfig:
>
> # Tasklet based software resend for pending interrupts on enable_irq()
> config HARDIRQS_SW_RESEND
>        bool
>
> According to
> commit a4633adcdbc15ac51afcd0e1395de58cee27cf92
>
>     [PATCH] genirq: add genirq sw IRQ-retrigger
>
>     Enable platforms that do not have a hardware-assisted
> hardirq-resend mechanism
>     to resend them via a softirq-driven IRQ emulation mechanism.
>
> so when enable_irq() is called, if the IRQ is already asserted,
> it will be distributed in the form of a software irq?
>
> OK I give up I don't understand the semantics of this thing.

Level type interrupts are "resending" in hardware as long as the device
interrupt is still asserted.

The problem are edge interrupts.

    When an edge interrupt is disabled via disable_irq() the core does
    not mask the chip because if the device raises an interrupt not all
    interrupt chips latch that and forward it to the CPU on unmask,
    i.e. some interrupt chips simply ignore an etch when the line is
    masked.

    So when the device raises an edge while the interrupt is disabled
    the core still handles the hardware interrupt and:

      - masks the interrupt line
      - sets the pending bit
      - does not invoke the device handler

    On enable_irq() the pending bit is checked and if set the interrupt
    is tried to be retriggered or resent, but only if it's edge type.
    
    So if the interrupt chip provides a irq_retrigger() callback the
    core uses that and only if this fails or is not available it resorts
    to software "resend" which means queueing it for execution in
    tasklet context.

> I see that ARM and ARM64 simply just select this. What
> happens if you do that and why is x86 not selecting it in general?

irq resending on X86 is not really problem free for interrupts
which are directly connect to the local APIC. The only way which is
halfways safe is the hardware retrigger. See

    https://lkml.kernel.org/r/20200306130623.590923677@linutronix.de
    https://lkml.kernel.org/r/20200306130623.684591280@linutronix.de

for the gory details. The GPIO interrupts which hang off behind some
slow bus or are multiplexed in other ways are not affected by this
hardware design induced madness.

As I don't know how many other architectures have trainwrecked interrupt
delivery mechanisms (IA64 definitely does), I'm more than reluctant to
inflict this on the world unconditionally.

Hope that helps.

Thanks,

        tglx

      parent reply	other threads:[~2020-03-12 15:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23 21:02 [RFC v2] x86: Select HARDIRQS_SW_RESEND on x86 Hans de Goede
2020-01-24 15:19 ` Thomas Gleixner
2020-03-11 18:24   ` Hans de Goede
2020-03-11 21:31     ` Thomas Gleixner
2020-03-11 21:49       ` Hans de Goede
2020-03-11 22:09         ` Thomas Gleixner
2020-03-12 12:06           ` Hans de Goede
2020-03-11 21:42 ` [tip: irq/core] " tip-bot2 for Hans de Goede
2020-03-12 13:31   ` Linus Walleij
2020-03-12 13:49     ` Hans de Goede
2020-03-12 14:02       ` Linus Walleij
2020-03-12 14:05         ` Hans de Goede
2020-03-12 15:55     ` Thomas Gleixner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mu8lin4e.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=hdegoede@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).