linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: <linux-arm-kernel@lists.infradead.org>, <catalin.marinas@arm.com>,
	<will@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Query on handling some special Group0 interrupt in Linux
Date: Wed, 09 Nov 2022 18:20:48 +0000	[thread overview]
Message-ID: <86tu38oupr.wl-maz@kernel.org> (raw)
In-Reply-To: <d7b70de6-cd7f-3724-3449-5b838a478277@quicinc.com>

On Wed, 09 Nov 2022 16:20:35 +0000,
Mukesh Ojha <quic_mojha@quicinc.com> wrote:
> 
> Hi,
> 
> I was working on a use case where both el2/el3 are implemented and we
> have a watchdog interrupt (SPI), which is used for detecting software
> hangs and cause device reset; If that interrupt's current cpu affinity
> is on a core, where interrupts are disabled, we won't be able to serve
> it or if this interrupt comes on a core which has interrupt enabled,
> calling panic() or with smp_send_stop(), we would not be able
> to know the call stack of the other cores which is running with
> interrupt disabled.
> 
> I was thinking of configuring both a watchdog irq(SPI) and IPI_STOP
> (SGI) or any reserve IPI as an FIQ. And from the watchdog irq handler,
> I was thinking of calling panic() which eventually sends IPI_STOP(SGI
> FIQ) to all the cores. And with this we will able to dump all the core
> call stack.
> 
> I am able to achieve this but wanted to know if this is acceptable to
> the community to support/allow such use cases like above and enable
> group0 interrupt from GIC for some special use cases.

For a start, we only deal with Group-1 interrupts in Linux. Group-0
interrupts are for the firmware, and we really don't want to see them
(this is consistent with your HW having EL3). We also mask IRQ and FIQ
at the same time, so this is a non-starter.

If you want to be able to deliver an interrupt while the interrupts
are masked, what you are looking for is the NMI framework, for which
you can register SPIs as (pseudo-)NMI.

This is of course assuming that you're using GICv3. If you're using an
older version of the architecture, we don't have a good solution for
you, unfortunately.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-11-09 18:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 16:20 Query on handling some special Group0 interrupt in Linux Mukesh Ojha
2022-11-09 18:20 ` Marc Zyngier [this message]
2022-11-09 19:57   ` Mukesh Ojha
2022-11-10  7:54     ` Marc Zyngier

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=86tu38oupr.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mojha@quicinc.com \
    --cc=tglx@linutronix.de \
    --cc=will@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).