opensbi.git/include/sbi/sbi_ipi.h, branch master

lib: sbi: Extends sbi_ipi_raw_send() to use all available IPI devices

2025-10-28T05:58:01Z

A platform may contain multiple IPI devices. In certain use cases, such as power management, it may be necessary to send an IPI through a specific device to wake up a CPU. For example, if an IMSIC is powered down and reset, the core cannot receive IPIs from it, so the wake-up must instead be triggered through the CLINT. Suggested-by: Anup Patel Signed-off-by: Nick Hu Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20251020-cache-upstream-v7-8-69a132447d8a@sifive.com Signed-off-by: Anup Patel

lib: sbi: Introduce IPI device rating

2025-09-16T04:26:31Z

A platform can have multiple IPI devices (such as ACLINT MSWI, AIA IMSIC, etc). Currently, OpenSBI rely on platform calling the sbi_ipi_set_device() function in correct order and prefer the first avaiable IPI device which is fragile. Instead of the above, introduce IPI device rating and prefer the highest rated IPI device. This further allows extending the sbi_ipi_raw_clear() to clear all available IPI devices. Signed-off-by: Anup Patel Tested-by: Nick Hu Link: https://lore.kernel.org/r/20250904052410.546818-2-apatel@ventanamicro.com Signed-off-by: Anup Patel

lib: sbi_ipi: Make .ipi_clear always target the current hart

2024-11-11T12:47:15Z

All existing users of this operation target the current hart, and it seems unlikely that a future user will need to clear the pending IPI status of a remote hart. Simplify the logic by changing .ipi_clear (and its wrapper sbi_ipi_raw_clear()) to always operate on the current hart. This incidentally fixes a bug introduced in commit 78c667b6fc07 ("lib: sbi: Prefer hartindex over hartid in IPI framework"), which changed the .ipi_clear parameter from a hartid to a hart index, but failed to update the warm_init functions to match. Fixes: 78c667b6fc07 ("lib: sbi: Prefer hartindex over hartid in IPI framework") Signed-off-by: Samuel Holland Reviewed-by: Anup Patel

lib: sbi: Prefer hartindex over hartid in IPI framework

2023-09-24T06:09:38Z

Let us prefer hartindex over hartid in IPI framework which in-turn forces IPI users to also prefer hartindex. Signed-off-by: Anup Patel

lib: sbi: improve the definition of SBI_IPI_EVENT_MAX

2023-09-06T11:36:12Z

The previous definition had the assumption that the machine word length is equal to the word length of LONG. Remove this assumption and add a static check to prevent errors in subsequent modifications. Signed-off-by: Xiang W Reviewed-by: Anup Patel

lib: sbi: Optimize sbi_tlb queue waiting

2023-04-14T08:15:30Z

When tlb_fifo is full, it will wait and affect the ipi update to other harts. This patch is optimized. Signed-off-by: Xiang W Reviewed-by: Anup Patel Tested-by: Anup Patel

lib: sbi: Clear IPIs before init_warm_startup in non-boot harts

2023-03-10T08:43:40Z

Since commit 50d4fde1c5a4 ("lib: Remove redundant sbi_platform_ipi_clear() calls"), the IPI sent from the boot hart in wake_coldboot_harts() is not cleared in the secondary harts until they reach sbi_ipi_init(). However, sbi_hsm_init() and sbi_hsm_hart_wait() are called earlier, so a secondary hart might enter sbi_hsm_hart_wait() with an already pending IPI. sbi_hsm_hart_wait() makes sure the hart leaves the loop only when it is actually ready, so a pending unrelated IPI should not cause safety issues. However, it might be inefficient on certain hardware, because it prevents "wfi" from stalling the hart even if the hardware supports this, making the hart needlessly spin in a "busy-wait" loop. This behaviour can be observed, for example, in a QEMU VM (QEMU 7.2.0) with "-machine virt" running a Linux guest. Inserting delays in sbi_hsm_hart_start() allows reproducing the issue more reliably. The comment in wait_for_coldboot() suggests that the initial IPI is needed in the warm resume path, so let us clear it before init_warm_startup() only. To do this, sbi_ipi_raw_clear() was created similar to sbi_ipi_raw_send(). Signed-off-by: Evgenii Shatokhin Reviewed-by: Anup Patel

lib: sbi: add check for ipi device for hsm start

2022-07-11T10:16:59Z

If the ecall SBI_EXT_HSM_HART_START is called it might try to wake the secondary hart using sbi_ipi_raw_send() to send an IPI to the hart. This can fail if there is no IPI device but no error is returned from sbi_ipi_raw_send() so the ecall returns as if the action completed and the caller continues without noticing (in the case of Linux it just hangs waiting for the secondary hart to become active) Fix this by changing sbi_ipi_raw_send() to return and error, and if an error is returned, then return it via SBI_EXT_HSM_HART_START call. Signed-off-by: Ben Dooks Reviewed-by: Anup Patel

lib: sbi: Simplify ipi platform operations

2021-04-28T11:33:31Z

Instead of having ipi_send() and ipi_clear() callbacks in platform operations, it will be much simpler for ipi driver to directly register these operations as a device to sbi_ipi implementation. Signed-off-by: Anup Patel Reviewed-by: Alistair Francis

include: sbi_ipi: Remove scratch parameter from most functions

2020-03-28T08:02:47Z

This patch removes scratch parameter from most sbi_ipi functions. Signed-off-by: Anup Patel Reviewed-by: Atish Patra