linux-kernel - Re: [PATCH V2 1/3] riscv: Add Zicbop instruction definitions & cpufeature

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: <20240111-populate-sterilize-8e241ead0b00@spud>
Date: Thu, 11 Jan 2024 11:12:33 +0000
From: Conor Dooley <conor@...nel.org>
To: Clément Léger <cleger@...osinc.com>
Cc: Andrew Jones <ajones@...tanamicro.com>, guoren@...nel.org,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Guo Ren <guoren@...ux.alibaba.com>, paul.walmsley@...ive.com,
	palmer@...belt.com, panqinglin2020@...as.ac.cn, bjorn@...osinc.com,
	conor.dooley@...rochip.com, leobras@...hat.com,
	peterz@...radead.org, keescook@...omium.org, wuwei2016@...as.ac.cn,
	xiaoguang.xing@...hgo.com, chao.wei@...hgo.com,
	unicorn_wang@...look.com, uwu@...nowy.me, jszhang@...nel.org,
	wefu@...hat.com, atishp@...shpatra.org
Subject: Re: [PATCH V2 1/3] riscv: Add Zicbop instruction definitions &
 cpufeature

On Thu, Jan 11, 2024 at 11:49:48AM +0100, Clément Léger wrote:
> 
> 
> On 11/01/2024 11:45, Andrew Jones wrote:
> > On Thu, Jan 11, 2024 at 11:31:32AM +0100, Clément Léger wrote:
> >>
> >>
> >> On 03/01/2024 13:00, Andrew Jones wrote:
> >>> On Wed, Jan 03, 2024 at 10:31:37AM +0100, Clément Léger wrote:
> >>>>
> >>>>
> >>>> On 31/12/2023 09:29, guoren@...nel.org wrote:
> >>>>> From: Guo Ren <guoren@...ux.alibaba.com>
> >>>>>
> >>>>> Cache-block prefetch instructions are HINTs to the hardware to
> >>>>> indicate that software intends to perform a particular type of
> >>>>> memory access in the near future. This patch adds prefetch.i,
> >>>>> prefetch.r and prefetch.w instruction definitions by
> >>>>> RISCV_ISA_EXT_ZICBOP cpufeature.
> >>>>>
> >>>>> Signed-off-by: Guo Ren <guoren@...ux.alibaba.com>
> >>>>> Signed-off-by: Guo Ren <guoren@...nel.org>
> >>>>> ---
> >>>>>  arch/riscv/Kconfig                | 15 ++++++++
> >>>>>  arch/riscv/include/asm/hwcap.h    |  1 +
> >>>>>  arch/riscv/include/asm/insn-def.h | 60 +++++++++++++++++++++++++++++++
> >>>>>  arch/riscv/kernel/cpufeature.c    |  1 +
> >>>>>  4 files changed, 77 insertions(+)
> >>>>>
> >>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> >>>>> index 24c1799e2ec4..fcbd417d65ea 100644
> >>>>> --- a/arch/riscv/Kconfig
> >>>>> +++ b/arch/riscv/Kconfig
> >>>>> @@ -579,6 +579,21 @@ config RISCV_ISA_ZICBOZ
> >>>>>  
> >>>>>  	   If you don't know what to do here, say Y.
> >>>>>  
> >>>>> +config RISCV_ISA_ZICBOP
> >>>>> +	bool "Zicbop extension support for cache block prefetch"
> >>>>> +	depends on MMU
> >>>>> +	depends on RISCV_ALTERNATIVE
> >>>>> +	default y
> >>>>> +	help
> >>>>> +	  Adds support to dynamically detect the presence of the ZICBOP
> >>>>> +	  extension (Cache Block Prefetch Operations) and enable its
> >>>>> +	  usage.
> >>>>> +
> >>>>> +	  The Zicbop extension can be used to prefetch cache block for
> >>>>> +	  read/write fetch.
> >>>>> +
> >>>>> +	  If you don't know what to do here, say Y.
> >>>>> +
> >>>>>  config TOOLCHAIN_HAS_ZIHINTPAUSE
> >>>>>  	bool
> >>>>>  	default y
> >>>>> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> >>>>> index 06d30526ef3b..77d3b6ee25ab 100644
> >>>>> --- a/arch/riscv/include/asm/hwcap.h
> >>>>> +++ b/arch/riscv/include/asm/hwcap.h
> >>>>> @@ -57,6 +57,7 @@
> >>>>>  #define RISCV_ISA_EXT_ZIHPM		42
> >>>>>  #define RISCV_ISA_EXT_SMSTATEEN		43
> >>>>>  #define RISCV_ISA_EXT_ZICOND		44
> >>>>> +#define RISCV_ISA_EXT_ZICBOP		45
> >>>>
> >>>> Hi Guo,
> >>>>
> >>>> Since you are adding support for the Zicbop extension, you could
> >>>> probably also allow to probe it from userspace using hwprobe. Add a few
> >>>> definitions to sys_riscv.c/hwprobe.h and it will be fine.
> >>>
> >>> To expose to userspace, we should also start parsing the block size,
> >>> so it can also be exposed to userspace. Starting to parse the block
> >>> size first requires that we decide we need to parse the block size
> >>> (see [1]).
> >>
> >> Hi Andrew, thanks for the thread.
> >>
> >> I read it (and the other ones that are related to it) and basically, it
> >> seems there was a first decision (expose Zicbop block size indivudally)
> >> due to the fact the specification did not mentioned anything specific
> >> about clock sizes  but then after that, there was a clarification in the
> >> spec stating that Zicbop and Zicbom have the same block size so the
> >> first decision was questioned again.
> >>
> >> From a user coherency point of view, I think it would make more sense to
> >> expose it individually in hwprobe  so that zicboz, zicbop and zicbom
> >> have their "own" block size (even though zicbop and zicbom would use the
> >> same one). Moreover, it would allow us for future evolution easily
> >> without breaking any userspace later if zicbop and zicbom block size are
> >> decoupled.
> > 
> > I agree and QEMU has already headed down the road of generating
> > riscv,cbop-block-size (I guess Conor's ack on [1] was interpreted as
> > being sufficient to merge the QEMU bits), so we can add the Linux
> > support and test with QEMU now. The work could probably be a separate
> > series to this one, though.
> 
> Yes, it QEMU had it merged. and agreed, since this requires a bit more
> plumbing, it can probably be left out of this series. I could probably
> take care of that later.

I think some crack slippage happened with that patch. I pinged Palmer
about it on irc.



Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)