[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86v7jftjq5.wl-maz@kernel.org>
Date: Wed, 12 Nov 2025 14:21:22 +0000
From: Marc Zyngier <maz@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: catalin.marinas@....com,
will@...nel.org,
mark.rutland@....com,
paulmck@...nel.org,
mhiramat@...nel.org,
linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
kernel-team@...a.com
Subject: Re: arm64: pseudo NMI bootconfig question
On Wed, 12 Nov 2025 14:05:43 +0000,
Breno Leitao <leitao@...ian.org> wrote:
>
> Hello,
>
> In most major Linux distributions, it’s common to have a separate debug kernel
> build. This variant is compiled with additional debug configuration options to
> provide deeper observability and easier debugging, typically at the expense of
> some performance.
>
> This approach is also used in several companies, including mine. The debug
> flavor is usually a drop-in replacement deployed when investigating
> issues, allowing quicker identification before more detailed manual
> debugging.
>
> I’m currently debugging some hung tasks using the debug kernel flavor and
> noticed that backtraces weren’t printed correctly because PSEUDO NMI isn’t
> enabled.
>
> AFAIK, to enable PSEUDO NMI on ARM, the following are required:
>
> cmdline: irqchip.gicv3_pseudo_nmi=1
> config: CONFIG_ARM64_PSEUDO_NMI=y
>
> I wanted to have pseudo NMI enabled by default in the debug kernel
> (without relying on kernel command-line parameters), but this isn’t
> possible today. The reason is that `irqchip.gicv3_pseudo_nmi` is an early
> parameter, which can’t be set through bootconfig, so, independent of my
> .config, I need to hack cmdline arguments to have the debuggability
> I need.
>
> Question:
>
> Would it make sense to provide an option to enable pseudo NMI in certain
> kernel configuration without requiring an extra command-line parameter?
[I wasn't asked, but I'll give my answer anyway]
The short answer is no. The long answer is that there is so much
broken HW out there that dies a painful death when enabling pseudo-NMI
that is isn't practical to do so. It also brings a measurable
overhead to some of the most frequent operations (interrupt masking).
Until someone weeds out the broken machines (in some cases, by prying
them from my cold dead hands), the requirement for the option is
likely to stick.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists