lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aOfmnjJmQAdR1wD4@pie>
Date: Thu, 9 Oct 2025 16:45:18 +0000
From: Yao Zi <ziyao@...root.org>
To: Yunhui Cui <cuiyunhui@...edance.com>, paul.walmsley@...ive.com,
	palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
	rostedt@...dmis.org, mhiramat@...nel.org, mark.rutland@....com,
	peterz@...radead.org, jpoimboe@...nel.org, jbaron@...mai.com,
	ardb@...nel.org, willy@...radead.org, guoren@...nel.org,
	ziy@...dia.com, akpm@...ux-foundation.org, bjorn@...osinc.com,
	ajones@...tanamicro.com, parri.andrea@...il.com,
	cleger@...osinc.com, yongxuan.wang@...ive.com, inochiama@...il.com,
	samuel.holland@...ive.com, charlie@...osinc.com,
	conor.dooley@...rochip.com, yikming2222@...il.com,
	andybnac@...il.com, yury.norov@...il.com,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] riscv: add support for Ziccid

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@...edance.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);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ