[PATCH RFC] riscv: add support for Ziccid
Yao Zi
ziyao at disroot.org
Thu Oct 9 09:45:18 PDT 2025
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.
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 <cuiyunhui at bytedance.com>
> ---
> 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);
More information about the linux-riscv
mailing list