Re: [PATCH] riscv: add system error interrupt handler support

[Conor Dooley]

On Fri, Feb 27, 2026 at 03:54:39PM +0800, Rui Qi wrote:
> On 2/26/26 5:22 PM, Conor Dooley wrote:
> > On Thu, Feb 26, 2026 at 04:27:35PM +0800, Rui Qi wrote:
> >> Add a system error interrupt handler for RISC-V that panics
> >> the system when hardware errors are detected. The implementation includes:
> >>
> >> - Add IRQ_SYS_ERROR (23) interrupt definition to CSR header
> >> - Implement sys_error.c module with panic handler
> >> - Register per-CPU interrupt handler for system error interrupts
> >> - Add module to kernel build system
> >>
> >> When a system error interrupt occurs, the handler immediately panics
> >> the system with a descriptive message to ensure the error is properly
> >> captured and the system is halted safely.
> >>
> >> Signed-off-by: Rui Qi <qirui.001@xxxxxxxxxxxxx>
> >> ---
> >>  arch/riscv/include/asm/csr.h  |  4 +-
> >>  arch/riscv/kernel/Makefile    |  1 +
> >>  arch/riscv/kernel/sys_error.c | 80 +++++++++++++++++++++++++++++++++++
> >>  include/linux/cpuhotplug.h    |  1 +
> >>  4 files changed, 85 insertions(+), 1 deletion(-)
> >>  create mode 100644 arch/riscv/kernel/sys_error.c
> >>
> >> diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
> >> index 31b8988f4488..1f43c25b07ed 100644
> >> --- a/arch/riscv/include/asm/csr.h
> >> +++ b/arch/riscv/include/asm/csr.h
> >> @@ -99,7 +99,8 @@
> >>  #define IRQ_M_EXT		11
> >>  #define IRQ_S_GEXT		12
> >>  #define IRQ_PMU_OVF		13
> >> -#define IRQ_LOCAL_MAX		(IRQ_PMU_OVF + 1)
> >> +#define IRQ_SYS_ERROR		23
> > 
> > Hmmm, two problems I think with this. 23 is one of the interrupts that
> > has been reserved for use with AIA. I don't think they use it right now,
> > but in the future it might see use there.
> > 
> > The first problem is kind of moot though, because reserving 16-23 for
> > AIA is a retcon, and previously these interrupts were available custom
> > use on any platform (as you have done here), so while it might be a
> > system error on your platform, it could be something completely innocuous
> > on mine!
> > 
> > With that in mind, does having this in arch code make sense at all?
> > Can this just be a normal driver, that'll only probe on your specific
> > platform?
> 
> Thanks for the comment.
> 
> I checked the latest RISC-V Interrupt Spec (2025-03-12). In that
> version, interrupts 16–23 are defined as architectural local interrupts,
> and interrupt 23 is tentatively proposed for a “Bus or system error”

Right, tentative is kinda no use to either of us though. Do you have
hardware that does this?

> type condition. That suggests this interrupt number is no longer just a
> free, platform-defined slot — it now carries architectural intent and a
> potential standardized meaning.

Emphasis on "potential", of course ;) Still a platform defined slot for
anyone that doesn't implement AIA, I think...
I don't understand the interaction between extensions and the priv spec
here, since the priv spec still says that 16 and higher are platform
specific.

> Given this context, my current implementation treats interrupt 23 as a
> local condition that matches the spec’s intent for a system-level error
> signal, rather than an arbitrary, custom platform interrupt. This seemed
> reasonable as long as it aligns with the architectural semantics for
> local interrupts.
> 
> That said, I’m open to the concern about placing this handling in
> arch/riscv, and I’d like to understand your preference: do you think
> this should be entirely moved into platform-specific code, or would a
> conditional, spec-aware arch implementation (e.g., gated on the presence
> of the relevant AIA/local interrupt support) be acceptable? Please let

It can't be gated on AIA, because AIA isn't the extension that says that
this is what interrupt 23 does (it specifically says that new extensions
are expected to define the use of the three interrupts "proposes"), and
we don't permit extension related stuff that is not frozen. I couldn't
find an extension at any stage that set the behaviour in stone, are you
aware of one? If one exists, a spec-aware arch implementation would be
okay. If one does not, you'll have to make this specific to your
platform until that extension shows up.

> me know what approach you’d suggest.

Attachment: signature.asc
Description: PGP signature