[PATCH v6 13/19] riscv: Fix race conditions when initializing IPI
seanga2 at gmail.com
Tue Mar 10 14:16:22 CET 2020
On 3/10/20 4:20 AM, Rick Chen wrote:
> Hi Sean
>> The IPI code could have race conditions in several places.
>> * Several harts could race on the value of gd->arch->clint/plic
>> * Non-boot harts could race with the main hart on the DM subsystem In
>> addition, if an IPI was pending when U-Boot started, it would cause the
>> IPI handler to jump to address 0.
>> To address these problems, a new function riscv_init_ipi is introduced. It
>> is called once during arch_cpu_init_dm. Before this point, no riscv_*_ipi
>> functions may be called. Access is synchronized by gd->arch->ipi_ready.
>> Signed-off-by: Sean Anderson <seanga2 at gmail.com>
>> Can you try to clear mip/sip in startup flow before secondary_hart_loop:
>> Maybe it can help to overcome the problem of calling riscv_clear_ipi()
>> before riscv_init_ipi() that you added.
> How is the verified result about trying to clear mip/sip in startup flow ?
> I have asked you twice in v5, but you still have no response about it.
> [PATCH v5 27/33] riscv: Fix race conditions when initializing IPI
I managed to get it working, and this patch incorporates that change.
However, I forgot to update the commit message. The original issue I had
was related to an accidental change to my config, and not to the
clearing of MIP.
More information about the U-Boot