From: Marc Zyngier <maz@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
paulmck@kernel.org, mhiramat@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: arm64: pseudo NMI bootconfig question
Date: Wed, 12 Nov 2025 14:21:22 +0000 [thread overview]
Message-ID: <86v7jftjq5.wl-maz@kernel.org> (raw)
In-Reply-To: <rs4igmsjrm6r2aio4nbe5jos3vcqk2u4bjhltjwtj2pn3cquip@kv3grgec7qrb>
On Wed, 12 Nov 2025 14:05:43 +0000,
Breno Leitao <leitao@debian.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.
next prev parent reply other threads:[~2025-11-12 14:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 14:05 arm64: pseudo NMI bootconfig question Breno Leitao
2025-11-12 14:21 ` Marc Zyngier [this message]
2025-11-13 9:36 ` Breno Leitao
2025-11-13 11:03 ` Will Deacon
2025-11-13 4:34 ` Masami Hiramatsu
2025-11-13 10:37 ` Breno Leitao
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=86v7jftjq5.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=paulmck@kernel.org \
--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).