From: "Radim Krčmář" <rkrcmar@ventanamicro.com>
To: "yunhui cui" <cuiyunhui@bytedance.com>
Cc: "Conor Dooley" <conor@kernel.org>, <paul.walmsley@sifive.com>,
<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <alex@ghiti.fr>,
<luxu.kernel@bytedance.com>, <atishp@rivosinc.com>,
<cleger@rivosinc.com>, <ajones@ventanamicro.com>,
<apatel@ventanamicro.com>, <linux-kernel@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <songshuaishuai@tinylab.org>,
<bjorn@rivosinc.com>, <charlie@rivosinc.com>,
<masahiroy@kernel.org>, <valentina.fernandezalanis@microchip.com>,
<jassisinghbrar@gmail.com>, <conor.dooley@microchip.com>,
"linux-riscv" <linux-riscv-bounces@lists.infradead.org>
Subject: Re: [External] Re: [PATCH 3/3] riscv: crash: use NMI to stop the CPU
Date: Mon, 03 Nov 2025 18:23:52 +0100 [thread overview]
Message-ID: <DDZ8G0K2921V.8B66OPQY2GXG@ventanamicro.com> (raw)
In-Reply-To: <CAEEQ3wk8w1q8Ujpq+6fyRPP+zqTy6_q22K-g681VZyVXstPaDg@mail.gmail.com>
2025-11-03T22:10:25+08:00, yunhui cui <cuiyunhui@bytedance.com>:
> Hi Radim,
>
> On Tue, Oct 28, 2025 at 8:36 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>>
>> 2025-10-28T10:42:12+00:00, Conor Dooley <conor@kernel.org>:
>> > On Mon, Oct 27, 2025 at 09:34:31PM +0800, Yunhui Cui wrote:
>> >> NMI is more robust than IPI for stopping CPUs during crashes,
>> >> especially with interrupts disabled. Add SBI_SSE_EVENT_LOCAL_CRASH_NMI
>> >> eventid to implement NMI for stopping CPUs.
>> >>
>> >> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
>> >> ---
>> >> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
>> >> @@ -487,6 +487,7 @@ enum sbi_sse_attr_id {
>> >> #define SBI_SSE_EVENT_GLOBAL_LOW_PRIO_RAS 0x00108000
>> >> #define SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED 0xffff0000
>> >> #define SBI_SSE_EVENT_LOCAL_UNKNOWN_NMI 0xffff0001
>> >> +#define SBI_SSE_EVENT_LOCAL_CRASH_NMI 0xffff0002
>>
>> This event isn't defined in the SBI pull request.
>>
>> I assume it's a pure software event that the platform shouldn't inject.
>> If we want to reserve more events for software use, why not make them
>> generic, like SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED?
>
> In fact, it's not just crash NMI, but also stop NMI, kgdb NMI, etc. An
> event can only register one SSE handler. If all use
> SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED, we'll have to execute each
> different NMI handler in sequence within the SSE handler, with each
> NMI handler checking for itself if there are NMIs of its type to
> process.
> Is that what you mean too?
My main point is that a platform doesn't seem to care what 0xffff0002 is
used for, so SBI could just assign a range of SSE event vectors for
software use, without trying to be overly specific about the purpose.
(I don't see a meaningful difference between 0xffff0000 and 0xffff0002.)
Demultiplexing a single SSE event vector is possible if event handlers
don't have to (or shouldn't) preempt each other.
I assume that we do need at least two software SSE event vectors, since
we should be able to interrupt other SSE handlers to execute the SSE
crash handler.
Do you think that two software SSE events are sufficient, or should we
aim to reserve more in SBI?
Thanks.
next prev parent reply other threads:[~2025-11-03 17:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 13:34 [PATCH 0/3] Add NMI Support to RISC-V via SSE Yunhui Cui
2025-10-27 13:34 ` [PATCH 1/3] drivers: firmware: riscv: add SSE NMI support Yunhui Cui
2025-10-28 10:53 ` Conor Dooley
2025-10-27 13:34 ` [PATCH 2/3] riscv: crash: move IPI crash handling logic to crash.c Yunhui Cui
2025-10-27 13:34 ` [PATCH 3/3] riscv: crash: use NMI to stop the CPU Yunhui Cui
2025-10-28 10:42 ` Conor Dooley
2025-10-28 12:36 ` Radim Krčmář
2025-11-03 14:10 ` [External] " yunhui cui
2025-11-03 17:23 ` Radim Krčmář [this message]
2025-11-03 13:36 ` yunhui cui
2025-10-30 8:46 ` Atish Patra
2025-10-31 1:24 ` Bagas Sanjaya
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=DDZ8G0K2921V.8B66OPQY2GXG@ventanamicro.com \
--to=rkrcmar@ventanamicro.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--cc=bjorn@rivosinc.com \
--cc=charlie@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=cuiyunhui@bytedance.com \
--cc=jassisinghbrar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv-bounces@lists.infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luxu.kernel@bytedance.com \
--cc=masahiroy@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=songshuaishuai@tinylab.org \
--cc=valentina.fernandezalanis@microchip.com \
/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