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

["Rui Qi" <qirui.001@bytedance.com>]

On 2/27/26 6:08 PM, Conor Dooley wrote:
> 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@bytedance.com>
>>>> ---
>>>>  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.

Thanks for the clarification — that makes sense.

You're right that AIA itself does not normatively define the semantics
of interrupt 23, and that the wording there is explicitly provisional. I
also understand the policy around not merging extension-related behavior
unless it is tied to a frozen specification.

My reasoning was based on the architectural direction indicated in the
interrupt spec, but I agree that “tentative” does not constitute a
stable architectural contract, and therefore isn't sufficient to justify
arch-level handling at this point.

Given that, I can move this into platform-specific code for now. If and
when a ratified extension formally assigns defined semantics to
interrupt 23, we could then revisit a spec-aware arch implementation
gated on that extension.

Please let me know if that approach aligns better with your expectations.