lib: sbi: Clear IPIs before init_warm_startup in non-boot hartsHEADVF2_v3.8.2VF2_v3.7.5VF2_v3.6.1VF2_v3.4.5VF2_v3.1.5VF2_v3.0.4VF2_v2.11.5VF2_6.1_v3.8.2VF2_6.1_v3.7.5JH7110_VF2_6.6_v5.12.0JH7110_VF2_6.1_v5.12.0JH7110_VF2_6.1_v5.11.4JH7110_VF2_6.1_v5.11.3JH7110_VF2_6.1_v5.10.3JH7110_VF2_6.1_v3.9.3JH7110_VF2_515_v5.12.0JH7110_VF2_515_v5.11.4JH7110_VF2_515_v5.11.3JH7110_VF2_515_v5.10.3JH7110_VF2_515_v3.9.3masterJH7110_VisionFive2_devel

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 <e.shatokhin@yadro.com>
Reviewed-by: Anup Patel <anup@brainfault.org>

0 files changed, 0 insertions, 0 deletions