From: "Troy Mitchell" <troy.mitchell@linux.dev>
To: "Bo Gan" <ganboing@gmail.com>,
"Troy Mitchell" <troy.mitchell@linux.dev>,
<opensbi@lists.infradead.org>
Cc: "Anup Patel" <anup@brainfault.org>,
"Nick Hu" <nick.hu@sifive.com>,
"Kevin Zhang" <zhangmeng.kevin@linux.spacemit.com>
Subject: Re: [PATCH] lib: sbi: Clear all IPI devices when processing an IPI
Date: Sat, 12 Sep 2026 17:09:12 +0800 [thread overview]
Message-ID: <DLD7XSBJKOJ2.3FFDZAGATV2LX@linux.dev> (raw)
In-Reply-To: <6cd2145e-b2fb-4f11-ba24-0c9b56554b40@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3067 bytes --]
Hi Bo,
On Fri Sep 11, 2026 at 5:32 PM +08, Bo Gan wrote:
> Hi Troy,
>
> On 9/8/26 06:00, Troy Mitchell wrote:
>> Hart start sends wake-up IPIs through all registered IPI devices, but
>> sbi_ipi_process() only clears the preferred device. A notification from
>> another device can arrive after warm initialization has cleared it.
>>
>> With both IMSIC and ACLINT MSWI, IMSIC is preferred and has no ipi_clear
>> callback: its interrupts are acknowledged through MTOPEI. A late ACLINT
>> notification therefore leaves MSIP asserted, trapping the hart in the
>> machine-mode interrupt handler and potentially timing out Linux CPU
>> bring-up.
>>
>> Clear all registered IPI devices before consuming the software IPI event
>> bits so that late wake-up notifications are acknowledged too.
>>
>> Fixes: 94f0f8465622 ("lib: sbi: Extends sbi_ipi_raw_send() to use all available IPI devices")
>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
>> ---
>> lib/sbi/sbi_ipi.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/sbi/sbi_ipi.c b/lib/sbi/sbi_ipi.c
>> index b04a5877..683d559d 100644
>> --- a/lib/sbi/sbi_ipi.c
>> +++ b/lib/sbi/sbi_ipi.c
>> @@ -263,7 +263,12 @@ void sbi_ipi_process(void)
>> sbi_scratch_offset_ptr(scratch, ipi_data_off);
>>
>> sbi_pmu_ctr_incr_fw(SBI_PMU_FW_IPI_RECVD);
>> - sbi_ipi_raw_clear(false);
>> + /*
>> + * A wake-up IPI is sent through all devices. A notification from a
>> + * non-preferred device can arrive after warm-boot initialization
>> + * cleared it, so acknowledge all devices when processing the IPI.
>> + */
>> + sbi_ipi_raw_clear(true);
>
> I feel like this is not the proper way to fix the issue. It introduces
> unnecessary overhead for *every* IPI processing, because you need to call
> clear on all IPI devices, even the non-preferred, inactive ones.
>
> IMO, the "int sbi_ipi_raw_send(u32 hartindex, bool all_devices)"
> interface is a bad idea. It opened the door for such issues. AFAIK, the
> only reason such interface exists is that sometimes, some platform
> requires the use of a different IPI device during HSM kicking. E.g.,
> some Sifive cores can't use imsic, but only aclint. Why not introduce
> another interface "int sbi_ipi_raw_send_safe(u32 hartindex)" just for this
> purpose? Then we can have a separate rating on how safe that IPI device
> could be for cold startup, and pick the right one in the function. E.g.,
> favor clint over imsic for sbi_ipi_raw_send_safe.
>
> In this way, we ensure that only 1 IPI is active at any given time, and
> ipi_process can still use sbi_ipi_raw_clear(false) to clear the preferred
> IPI device, and HSM/init code still does sbi_ipi_raw_clear(true). There'd
> be no more cases like Troy encountered, where IPI from another device
> arrives late, and you have no ideal way of dealing with it other than what
> Troy was proposing.
>
> Let me test with this approach and prepare a patchset.
Ok. wait for your feedback.
--
Troy Mitchell
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
[-- Attachment #2: Type: text/plain, Size: 105 bytes --]
--
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi
next prev parent reply other threads:[~2026-09-12 9:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 13:00 [PATCH] lib: sbi: Clear all IPI devices when processing an IPI Troy Mitchell
2026-09-11 9:32 ` Bo Gan
2026-09-12 9:09 ` Troy Mitchell [this message]
2026-09-13 10:04 ` Bo Gan
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=DLD7XSBJKOJ2.3FFDZAGATV2LX@linux.dev \
--to=troy.mitchell@linux.dev \
--cc=anup@brainfault.org \
--cc=ganboing@gmail.com \
--cc=nick.hu@sifive.com \
--cc=opensbi@lists.infradead.org \
--cc=zhangmeng.kevin@linux.spacemit.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