linux-kernel - Re: [External] Re: [PATCH RFC] riscv: add support for Ziccid

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] [day] [month] [year] [list]

Message-ID: <CAEEQ3wkH5FZSOGPhu7i7UDyi5=Xe6B9q7=4_ZZN_R2BHi63J1A@mail.gmail.com>
Date: Thu, 16 Oct 2025 17:24:26 +0800
From: yunhui cui <cuiyunhui@...edance.com>
To: Yao Zi <ziyao@...root.org>
Cc: 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: [External] Re: [PATCH RFC] riscv: add support for Ziccid

Hi Yao,

On Fri, Oct 10, 2025 at 12:46 AM Yao Zi <ziyao@...root.org> 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 <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);


Thanks,
Yunhui