Hi Yao, On Fri, Oct 10, 2025 at 12:46 AM Yao Zi <[email protected]> wrote: > > On Thu, Oct 09, 2025 at 09:45:14PM +0800, Yunhui Cui wrote: > > The Ziccid extension provides hardware synchronization between > > Dcache and Icache. With this hardware support, there's no longer > > a need to trigger remote hart execution of fence.i via IPI. > > This description looks wrong to me: Ziccid only guarantees code > modification **eventually** becomes visible to remote HARTs, not > immediately. Quoting a paragraph from documentation of Ziccid[1], > > > Since, under Ziccid, instruction fetches appear in the global memory > > order, the RVWMO progress axiom suffices to guarantee that stores > > **eventually** become visible to instruction fetches, even without > > executing a FENCE.I instruction. > > and an issue[2] in the same repository (Ziccid hardware implementation & > software model), > > > > Is fence.i still necessary in any case with the presence of Ziccid > > > > The only thing that Ziccid guarantees is that stores eventually become > > visible to instruction fetch. It doesn't guarantee that stores > > immediately become visible to instruction fetch, even on the same > > hart. > > > > So, fence.i is still usually necessary. The only situations in which > > fence.i is not necessary is when race conditions in code patching are > > functionally acceptable, i.e. when it doesn't matter whether the old > > code or new code is executed.
Well, yes, based on this link, no additional software support is needed—and that’s also a good thing. https://github.com/aswaterman/riscv-misc/issues/4 > > So it's definitely wrong to state "there's no longer a need to trigger > remote hart execution of fence.i". > > > Signed-off-by: Yunhui Cui <[email protected]> > > --- > > arch/riscv/include/asm/cacheflush.h | 4 ++-- > > arch/riscv/include/asm/hwcap.h | 1 + > > arch/riscv/include/asm/switch_to.h | 10 ++++++++++ > > arch/riscv/kernel/cpufeature.c | 1 + > > arch/riscv/kernel/ftrace.c | 2 +- > > arch/riscv/kernel/hibernate.c | 2 +- > > arch/riscv/kernel/jump_label.c | 2 +- > > arch/riscv/mm/cacheflush.c | 16 ++++++++++++++-- > > 8 files changed, 31 insertions(+), 7 deletions(-) > > > > ... > > > -void flush_icache_all(void) > > +void flush_icache_all(bool force) > > { > > local_flush_icache_all(); > > > > if (num_online_cpus() < 2) > > return; > > > > + if (!force) > > + asm goto(ALTERNATIVE("nop", "j %l[ziccid]", 0, > > + RISCV_ISA_EXT_ZICCID, 1) > > + : : : : ziccid); > > and even in the patch, a remote-fence is still triggered if > flush_icache_all() is called with force set to true. > > Best regards, > Yao Zi > > [1]: > https://github.com/aswaterman/riscv-misc/blob/e4fe3aa7b4d5b/isa/ziccid.adoc?plain=1#L139-L158 > [2]: https://github.com/aswaterman/riscv-misc/issues/4#issuecomment-2884984633 > > > /* > > * Make sure all previous writes to the D$ are ordered before making > > * the IPI. The RISC-V spec states that a hart must execute a data > > fence > > @@ -41,6 +46,7 @@ void flush_icache_all(void) > > sbi_remote_fence_i(NULL); > > else > > on_each_cpu(ipi_remote_fence_i, NULL, 1); > > +ziccid:; > > } > > EXPORT_SYMBOL(flush_icache_all); Thanks, Yunhui
