* [PATCH 0/3] RISC-V: archrandom support
@ 2023-06-27 14:37 Samuel Ortiz
2023-06-27 14:37 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Samuel Ortiz
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Samuel Ortiz @ 2023-06-27 14:37 UTC (permalink / raw)
To: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv
Cc: Samuel Ortiz, linux, Conor Dooley, Andrew Jones, Heiko Stuebner,
Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren,
Atish Patra, Björn Töpel, Evan Green
This patchset adds support for the archrandom API to the RISC-V
architecture.
The ratified crypto scalar extensions provide entropy bits via the seed
CSR, as exposed by the Zkr extension.
The first patch of this patchset allows for detecting support of the Zbc
and all scalar crypto extensions.
The second patch exposes the Zbc and scalar crypto extensions through
the hwprobe syscall.
The last patch relies on the first ones to check for the Zkr support,
and implements get_random_seed_longs by looping through a seed CSR
read-write to return one long worth of entropy.
Hongren (Zenithal) Zheng (1):
RISC-V: add Bitmanip/Scalar Crypto parsing from DT
Samuel Ortiz (2):
RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions
RISC-V: Implement archrandom when Zkr is available
Documentation/riscv/hwprobe.rst | 33 ++++++++++++++
arch/riscv/include/asm/archrandom.h | 66 +++++++++++++++++++++++++++
arch/riscv/include/asm/csr.h | 9 ++++
arch/riscv/include/asm/hwcap.h | 11 +++++
arch/riscv/include/uapi/asm/hwprobe.h | 11 +++++
arch/riscv/kernel/cpu.c | 11 +++++
arch/riscv/kernel/cpufeature.c | 30 ++++++++++++
arch/riscv/kernel/sys_riscv.c | 36 +++++++++------
8 files changed, 193 insertions(+), 14 deletions(-)
create mode 100644 arch/riscv/include/asm/archrandom.h
base-commit: 488833ccdcac118da16701f4ee0673b20ba47fe3
--
2.41.0
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 14:37 [PATCH 0/3] RISC-V: archrandom support Samuel Ortiz @ 2023-06-27 14:37 ` Samuel Ortiz 2023-06-27 18:14 ` Evan Green [not found] ` <97a7d701-3b48-252e-6d78-ef3d0e7f8f03@web.de> 2023-06-27 14:37 ` [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions Samuel Ortiz 2023-06-27 14:37 ` [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available Samuel Ortiz 2 siblings, 2 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-27 14:37 UTC (permalink / raw) To: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: Hongren (Zenithal) Zheng, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Samuel Ortiz, Björn Töpel, Evan Green, Jiatai He From: "Hongren (Zenithal) Zheng" <i@zenithal.me> This patch parses Zb/Zk related string from DT and output them in cpuinfo One thing worth noting is that if DT provides zk, all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. Note that zk is a valid extension name and the current DT binding spec allows this. This patch also changes the logical id of existing multi-letter extensions and adds a statement that instead of logical id compatibility, the order is needed. There currently lacks a mechanism to merge them when producing cpuinfo. Namely if you provide a riscv,isa "rv64imafdc_zk_zks", the cpuinfo output would be "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed _zksh_zkt" Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> --- arch/riscv/include/asm/hwcap.h | 11 +++++++++++ arch/riscv/kernel/cpu.c | 11 +++++++++++ arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index f041bfa7f6a0..b80ca6e77088 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -53,6 +53,17 @@ #define RISCV_ISA_EXT_ZICSR 40 #define RISCV_ISA_EXT_ZIFENCEI 41 #define RISCV_ISA_EXT_ZIHPM 42 +#define RISCV_ISA_EXT_ZBC 43 +#define RISCV_ISA_EXT_ZBKB 44 +#define RISCV_ISA_EXT_ZBKC 45 +#define RISCV_ISA_EXT_ZBKX 46 +#define RISCV_ISA_EXT_ZKND 47 +#define RISCV_ISA_EXT_ZKNE 48 +#define RISCV_ISA_EXT_ZKNH 49 +#define RISCV_ISA_EXT_ZKR 50 +#define RISCV_ISA_EXT_ZKSED 51 +#define RISCV_ISA_EXT_ZKSH 52 +#define RISCV_ISA_EXT_ZKT 53 #define RISCV_ISA_EXT_MAX 64 #define RISCV_ISA_EXT_NAME_LEN_MAX 32 diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index a2fc952318e9..10524322a4c0 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index bdcf460ea53d..447f853a5a4c 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); + SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC); + SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX); SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); SET_ISA_EXT_MAP("zicboz", RISCV_ISA_EXT_ZICBOZ); SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); + SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED); + SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH); + SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR); + SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT); + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB); + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC); + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX); + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND); + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE); + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH); + SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND); + SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE); + SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH); + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB); + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC); + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX); + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED); + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR); + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT); } #undef SET_ISA_EXT_MAP } -- 2.41.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 14:37 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Samuel Ortiz @ 2023-06-27 18:14 ` Evan Green 2023-06-27 18:44 ` Hongren (Zenithal) Zheng 2023-06-27 18:48 ` Conor Dooley [not found] ` <97a7d701-3b48-252e-6d78-ef3d0e7f8f03@web.de> 1 sibling, 2 replies; 27+ messages in thread From: Evan Green @ 2023-06-27 18:14 UTC (permalink / raw) To: Samuel Ortiz Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > This patch parses Zb/Zk related string from DT and > output them in cpuinfo > > One thing worth noting is that if DT provides zk, > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > Note that zk is a valid extension name and the current > DT binding spec allows this. > > This patch also changes the logical id of > existing multi-letter extensions and adds a statement > that instead of logical id compatibility, the order > is needed. > > There currently lacks a mechanism to merge them when > producing cpuinfo. Namely if you provide a riscv,isa > "rv64imafdc_zk_zks", the cpuinfo output would be > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > _zksh_zkt" > > Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> > Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> > --- > arch/riscv/include/asm/hwcap.h | 11 +++++++++++ > arch/riscv/kernel/cpu.c | 11 +++++++++++ > arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ > 3 files changed, 52 insertions(+) > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > index f041bfa7f6a0..b80ca6e77088 100644 > --- a/arch/riscv/include/asm/hwcap.h > +++ b/arch/riscv/include/asm/hwcap.h > @@ -53,6 +53,17 @@ > #define RISCV_ISA_EXT_ZICSR 40 > #define RISCV_ISA_EXT_ZIFENCEI 41 > #define RISCV_ISA_EXT_ZIHPM 42 > +#define RISCV_ISA_EXT_ZBC 43 > +#define RISCV_ISA_EXT_ZBKB 44 > +#define RISCV_ISA_EXT_ZBKC 45 > +#define RISCV_ISA_EXT_ZBKX 46 > +#define RISCV_ISA_EXT_ZKND 47 > +#define RISCV_ISA_EXT_ZKNE 48 > +#define RISCV_ISA_EXT_ZKNH 49 > +#define RISCV_ISA_EXT_ZKR 50 > +#define RISCV_ISA_EXT_ZKSED 51 > +#define RISCV_ISA_EXT_ZKSH 52 > +#define RISCV_ISA_EXT_ZKT 53 > > #define RISCV_ISA_EXT_MAX 64 > #define RISCV_ISA_EXT_NAME_LEN_MAX 32 > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > index a2fc952318e9..10524322a4c0 100644 > --- a/arch/riscv/kernel/cpu.c > +++ b/arch/riscv/kernel/cpu.c > @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), > __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), > __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index bdcf460ea53d..447f853a5a4c 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); > + SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC); > + SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX); Should "zbks" be "zbkx"? > SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); > SET_ISA_EXT_MAP("zicboz", RISCV_ISA_EXT_ZICBOZ); > SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); > + SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED); > + SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH); > + SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR); > + SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT); > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB); > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC); > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX); > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND); > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE); > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH); > + SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND); > + SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE); > + SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH); > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB); > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC); > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX); > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED); > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR); > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT); It would be nice to consolidate the ones together that search for a single string and set multiple bits, though I don't have any super elegant ideas for how off the top of my head. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 18:14 ` Evan Green @ 2023-06-27 18:44 ` Hongren (Zenithal) Zheng 2023-06-27 18:48 ` Conor Dooley 1 sibling, 0 replies; 27+ messages in thread From: Hongren (Zenithal) Zheng @ 2023-06-27 18:44 UTC (permalink / raw) To: Evan Green Cc: Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > > > This patch parses Zb/Zk related string from DT and > > output them in cpuinfo > > > > One thing worth noting is that if DT provides zk, > > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > > > Note that zk is a valid extension name and the current > > DT binding spec allows this. > > > > This patch also changes the logical id of > > existing multi-letter extensions and adds a statement > > that instead of logical id compatibility, the order > > is needed. > > > > There currently lacks a mechanism to merge them when > > producing cpuinfo. Namely if you provide a riscv,isa > > "rv64imafdc_zk_zks", the cpuinfo output would be > > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > > _zksh_zkt" > > > > Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> > > Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> I think an extra line of your own signed-off-by is needed > > --- > > arch/riscv/include/asm/hwcap.h | 11 +++++++++++ > > arch/riscv/kernel/cpu.c | 11 +++++++++++ > > arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ > > 3 files changed, 52 insertions(+) > > > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > > index f041bfa7f6a0..b80ca6e77088 100644 > > --- a/arch/riscv/include/asm/hwcap.h > > +++ b/arch/riscv/include/asm/hwcap.h > > @@ -53,6 +53,17 @@ > > #define RISCV_ISA_EXT_ZICSR 40 > > #define RISCV_ISA_EXT_ZIFENCEI 41 > > #define RISCV_ISA_EXT_ZIHPM 42 > > +#define RISCV_ISA_EXT_ZBC 43 > > +#define RISCV_ISA_EXT_ZBKB 44 > > +#define RISCV_ISA_EXT_ZBKC 45 > > +#define RISCV_ISA_EXT_ZBKX 46 > > +#define RISCV_ISA_EXT_ZKND 47 > > +#define RISCV_ISA_EXT_ZKNE 48 > > +#define RISCV_ISA_EXT_ZKNH 49 > > +#define RISCV_ISA_EXT_ZKR 50 > > +#define RISCV_ISA_EXT_ZKSED 51 > > +#define RISCV_ISA_EXT_ZKSH 52 > > +#define RISCV_ISA_EXT_ZKT 53 > > > > #define RISCV_ISA_EXT_MAX 64 > > #define RISCV_ISA_EXT_NAME_LEN_MAX 32 > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > > index a2fc952318e9..10524322a4c0 100644 > > --- a/arch/riscv/kernel/cpu.c > > +++ b/arch/riscv/kernel/cpu.c > > @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > > __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), > > __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > > __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > > __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > > __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), > > __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), > > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > index bdcf460ea53d..447f853a5a4c 100644 > > --- a/arch/riscv/kernel/cpufeature.c > > +++ b/arch/riscv/kernel/cpufeature.c > > @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) > > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > > SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > > SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > > SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > > + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX); > > Should "zbks" be "zbkx"? Yes that is a nice catch! > > > SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); > > SET_ISA_EXT_MAP("zicboz", RISCV_ISA_EXT_ZICBOZ); > > SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); > > + SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED); > > + SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH); > > + SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR); > > + SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH); > > + SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND); > > + SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE); > > + SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT); > > It would be nice to consolidate the ones together that search for a > single string and set multiple bits, though I don't have any super > elegant ideas for how off the top of my head. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 18:14 ` Evan Green 2023-06-27 18:44 ` Hongren (Zenithal) Zheng @ 2023-06-27 18:48 ` Conor Dooley 2023-06-27 19:03 ` Hongren (Zenithal) Zheng 2023-06-28 10:01 ` Samuel Ortiz 1 sibling, 2 replies; 27+ messages in thread From: Conor Dooley @ 2023-06-27 18:48 UTC (permalink / raw) To: Evan Green Cc: Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He [-- Attachment #1: Type: text/plain, Size: 8053 bytes --] On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > > > This patch parses Zb/Zk related string from DT and %s/This patch// > > output them in cpuinfo > > > > One thing worth noting is that if DT provides zk, > > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. Please explain why this is okay. > > Note that zk is a valid extension name and the current > > DT binding spec allows this. > > > > This patch also changes the logical id of > > existing multi-letter extensions and adds a statement > > that instead of logical id compatibility, the order > > is needed. Does it? > > There currently lacks a mechanism to merge them when > > producing cpuinfo. Namely if you provide a riscv,isa > > "rv64imafdc_zk_zks", the cpuinfo output would be > > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > > _zksh_zkt" I think this is fine. Please re-wrap this all to 72 characters. > > > > Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> > > Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> This is missing your SoB Samuel. > > --- > > arch/riscv/include/asm/hwcap.h | 11 +++++++++++ > > arch/riscv/kernel/cpu.c | 11 +++++++++++ > > arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ > > 3 files changed, 52 insertions(+) > > > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > > index f041bfa7f6a0..b80ca6e77088 100644 > > --- a/arch/riscv/include/asm/hwcap.h > > +++ b/arch/riscv/include/asm/hwcap.h > > @@ -53,6 +53,17 @@ > > #define RISCV_ISA_EXT_ZICSR 40 > > #define RISCV_ISA_EXT_ZIFENCEI 41 > > #define RISCV_ISA_EXT_ZIHPM 42 > > +#define RISCV_ISA_EXT_ZBC 43 > > +#define RISCV_ISA_EXT_ZBKB 44 > > +#define RISCV_ISA_EXT_ZBKC 45 > > +#define RISCV_ISA_EXT_ZBKX 46 > > +#define RISCV_ISA_EXT_ZKND 47 > > +#define RISCV_ISA_EXT_ZKNE 48 > > +#define RISCV_ISA_EXT_ZKNH 49 > > +#define RISCV_ISA_EXT_ZKR 50 > > +#define RISCV_ISA_EXT_ZKSED 51 > > +#define RISCV_ISA_EXT_ZKSH 52 > > +#define RISCV_ISA_EXT_ZKT 53 > > > > #define RISCV_ISA_EXT_MAX 64 > > #define RISCV_ISA_EXT_NAME_LEN_MAX 32 > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > > index a2fc952318e9..10524322a4c0 100644 > > --- a/arch/riscv/kernel/cpu.c > > +++ b/arch/riscv/kernel/cpu.c > > @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > > __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), > > __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > > __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > > __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > > __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), > > __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), > > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > index bdcf460ea53d..447f853a5a4c 100644 > > --- a/arch/riscv/kernel/cpufeature.c > > +++ b/arch/riscv/kernel/cpufeature.c > > @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) > > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > > SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > > SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > > SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > > + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); This order does not look correct, please add them in alphanumerical order as the comment these SET_ISA_EXT_MAP()s requests. Ditto below. > > + SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX); > > Should "zbks" be "zbkx"? > > > SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); > > SET_ISA_EXT_MAP("zicboz", RISCV_ISA_EXT_ZICBOZ); > > SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); > > + SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED); > > + SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH); > > + SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR); > > + SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE); > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH); > > + SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND); > > + SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE); > > + SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED); > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR); > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT); > > It would be nice to consolidate the ones together that search for a > single string and set multiple bits, though I don't have any super > elegant ideas for how off the top of my head. I've got a refactor of this code in progress, dropping all of these copy-paste in place of a loop. It certainly looks more elegant than this, but it will fall over a bit for these "one string matches many extensions" cases. See here: https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ My immediate thought is to add another element to riscv_isa_ext_data, that contains "parent" extensions to check for. Should be fairly doable, I'll whip something up on top of that... Cheers, Conor. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 18:48 ` Conor Dooley @ 2023-06-27 19:03 ` Hongren (Zenithal) Zheng 2023-06-27 19:18 ` Conor Dooley 2023-06-28 9:59 ` Samuel Ortiz 2023-06-28 10:01 ` Samuel Ortiz 1 sibling, 2 replies; 27+ messages in thread From: Hongren (Zenithal) Zheng @ 2023-06-27 19:03 UTC (permalink / raw) To: Conor Dooley Cc: Evan Green, Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > > > > > This patch parses Zb/Zk related string from DT and > > %s/This patch// > > > > output them in cpuinfo > > > > > > One thing worth noting is that if DT provides zk, > > > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > Please explain why this is okay. From riscv scalar crypto spec, zk is a shorthand for zkn, zkr and zkt and zkn also includes zbkb, zbkc and zbkx. > > > > Note that zk is a valid extension name and the current > > > DT binding spec allows this. > > > > > > This patch also changes the logical id of > > > existing multi-letter extensions and adds a statement > > > that instead of logical id compatibility, the order > > > is needed. > > Does it? That is in the old version of this patch, should be removed now see https://lore.kernel.org/linux-riscv/YqY0aSngjI0Hc5d4@Sun/ > > > > There currently lacks a mechanism to merge them when > > > producing cpuinfo. Namely if you provide a riscv,isa > > > "rv64imafdc_zk_zks", the cpuinfo output would be > > > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > > > _zksh_zkt" > > I think this is fine. > > Please re-wrap this all to 72 characters. > > > > > > > Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> > > > Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> > > This is missing your SoB Samuel. > > > > --- > > > arch/riscv/include/asm/hwcap.h | 11 +++++++++++ > > > arch/riscv/kernel/cpu.c | 11 +++++++++++ > > > arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ > > > 3 files changed, 52 insertions(+) > > > > > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > > > index f041bfa7f6a0..b80ca6e77088 100644 > > > --- a/arch/riscv/include/asm/hwcap.h > > > +++ b/arch/riscv/include/asm/hwcap.h > > > @@ -53,6 +53,17 @@ > > > #define RISCV_ISA_EXT_ZICSR 40 > > > #define RISCV_ISA_EXT_ZIFENCEI 41 > > > #define RISCV_ISA_EXT_ZIHPM 42 > > > +#define RISCV_ISA_EXT_ZBC 43 > > > +#define RISCV_ISA_EXT_ZBKB 44 > > > +#define RISCV_ISA_EXT_ZBKC 45 > > > +#define RISCV_ISA_EXT_ZBKX 46 > > > +#define RISCV_ISA_EXT_ZKND 47 > > > +#define RISCV_ISA_EXT_ZKNE 48 > > > +#define RISCV_ISA_EXT_ZKNH 49 > > > +#define RISCV_ISA_EXT_ZKR 50 > > > +#define RISCV_ISA_EXT_ZKSED 51 > > > +#define RISCV_ISA_EXT_ZKSH 52 > > > +#define RISCV_ISA_EXT_ZKT 53 > > > > > > #define RISCV_ISA_EXT_MAX 64 > > > #define RISCV_ISA_EXT_NAME_LEN_MAX 32 > > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > > > index a2fc952318e9..10524322a4c0 100644 > > > --- a/arch/riscv/kernel/cpu.c > > > +++ b/arch/riscv/kernel/cpu.c > > > @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > > > __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), > > > __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > > > __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > > > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > > > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > > > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > > > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > > > __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > > > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > > > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > > > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > > > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > > > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > > > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > > > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > > > __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), > > > __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), > > > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > index bdcf460ea53d..447f853a5a4c 100644 > > > --- a/arch/riscv/kernel/cpufeature.c > > > +++ b/arch/riscv/kernel/cpufeature.c > > > @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) > > > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > > > SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > > > SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > > > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > > > SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > > > + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); > > This order does not look correct, please add them in alphanumerical > order as the comment these SET_ISA_EXT_MAP()s requests. Ditto below. Agreed. Seems that I did not worked carefully for this part. > > > > + SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX); > > > > Should "zbks" be "zbkx"? > > > > > SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); > > > SET_ISA_EXT_MAP("zicboz", RISCV_ISA_EXT_ZICBOZ); > > > SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); > > > + SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED); > > > + SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH); > > > + SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR); > > > + SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH); > > > + SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND); > > > + SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE); > > > + SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT); > > > > It would be nice to consolidate the ones together that search for a > > single string and set multiple bits, though I don't have any super > > elegant ideas for how off the top of my head. > > I've got a refactor of this code in progress, dropping all of these > copy-paste in place of a loop. It certainly looks more elegant than > this, but it will fall over a bit for these "one string matches many > extensions" cases. See here: > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > My immediate thought is to add another element to riscv_isa_ext_data, > that contains "parent" extensions to check for. Should be fairly doable, > I'll whip something up on top of that... > > Cheers, > Conor. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 19:03 ` Hongren (Zenithal) Zheng @ 2023-06-27 19:18 ` Conor Dooley 2023-06-28 9:59 ` Samuel Ortiz 1 sibling, 0 replies; 27+ messages in thread From: Conor Dooley @ 2023-06-27 19:18 UTC (permalink / raw) To: Hongren (Zenithal) Zheng Cc: Evan Green, Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He [-- Attachment #1: Type: text/plain, Size: 944 bytes --] On Wed, Jun 28, 2023 at 03:03:58AM +0800, Hongren (Zenithal) Zheng wrote: > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > > > > > > > This patch parses Zb/Zk related string from DT and > > > > %s/This patch// > > > > > > output them in cpuinfo > > > > > > > > One thing worth noting is that if DT provides zk, > > > > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > > > Please explain why this is okay. > > From riscv scalar crypto spec, zk is a shorthand > for zkn, zkr and zkt and zkn also includes zbkb, zbkc > and zbkx. Hmm, seems you misunderstood, sorry about that. What I was looking for is an explanation of this in the commit message. Hope that helps, Conor. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 19:03 ` Hongren (Zenithal) Zheng 2023-06-27 19:18 ` Conor Dooley @ 2023-06-28 9:59 ` Samuel Ortiz 1 sibling, 0 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-28 9:59 UTC (permalink / raw) To: Hongren (Zenithal) Zheng Cc: Conor Dooley, Evan Green, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Wed, Jun 28, 2023 at 03:03:58AM +0800, Hongren (Zenithal) Zheng wrote: > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > > > > > > > This patch parses Zb/Zk related string from DT and > > > > %s/This patch// > > > > > > output them in cpuinfo > > > > > > > > One thing worth noting is that if DT provides zk, > > > > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > > > Please explain why this is okay. > > From riscv scalar crypto spec, zk is a shorthand > for zkn, zkr and zkt and zkn also includes zbkb, zbkc > and zbkx. > > > > > > > Note that zk is a valid extension name and the current > > > > DT binding spec allows this. > > > > > > > > This patch also changes the logical id of > > > > existing multi-letter extensions and adds a statement > > > > that instead of logical id compatibility, the order > > > > is needed. > > > > Does it? > > That is in the old version of this patch, > should be removed now > see https://lore.kernel.org/linux-riscv/YqY0aSngjI0Hc5d4@Sun/ > > > > > > > There currently lacks a mechanism to merge them when > > > > producing cpuinfo. Namely if you provide a riscv,isa > > > > "rv64imafdc_zk_zks", the cpuinfo output would be > > > > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > > > > _zksh_zkt" > > > > I think this is fine. > > > > Please re-wrap this all to 72 characters. > > > > > > > > > > Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> > > > > Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> > > > > This is missing your SoB Samuel. > > > > > > --- > > > > arch/riscv/include/asm/hwcap.h | 11 +++++++++++ > > > > arch/riscv/kernel/cpu.c | 11 +++++++++++ > > > > arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ > > > > 3 files changed, 52 insertions(+) > > > > > > > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > > > > index f041bfa7f6a0..b80ca6e77088 100644 > > > > --- a/arch/riscv/include/asm/hwcap.h > > > > +++ b/arch/riscv/include/asm/hwcap.h > > > > @@ -53,6 +53,17 @@ > > > > #define RISCV_ISA_EXT_ZICSR 40 > > > > #define RISCV_ISA_EXT_ZIFENCEI 41 > > > > #define RISCV_ISA_EXT_ZIHPM 42 > > > > +#define RISCV_ISA_EXT_ZBC 43 > > > > +#define RISCV_ISA_EXT_ZBKB 44 > > > > +#define RISCV_ISA_EXT_ZBKC 45 > > > > +#define RISCV_ISA_EXT_ZBKX 46 > > > > +#define RISCV_ISA_EXT_ZKND 47 > > > > +#define RISCV_ISA_EXT_ZKNE 48 > > > > +#define RISCV_ISA_EXT_ZKNH 49 > > > > +#define RISCV_ISA_EXT_ZKR 50 > > > > +#define RISCV_ISA_EXT_ZKSED 51 > > > > +#define RISCV_ISA_EXT_ZKSH 52 > > > > +#define RISCV_ISA_EXT_ZKT 53 > > > > > > > > #define RISCV_ISA_EXT_MAX 64 > > > > #define RISCV_ISA_EXT_NAME_LEN_MAX 32 > > > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > > > > index a2fc952318e9..10524322a4c0 100644 > > > > --- a/arch/riscv/kernel/cpu.c > > > > +++ b/arch/riscv/kernel/cpu.c > > > > @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > > > > __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), > > > > __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > > > > __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > > > > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > > > > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > > > > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > > > > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > > > > __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > > > > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > > > > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > > > > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > > > > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > > > > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > > > > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > > > > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > > > > __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), > > > > __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), > > > > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > > index bdcf460ea53d..447f853a5a4c 100644 > > > > --- a/arch/riscv/kernel/cpufeature.c > > > > +++ b/arch/riscv/kernel/cpufeature.c > > > > @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) > > > > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > > > > SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > > > > SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > > > > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > > > > SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > > > > + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); > > > > This order does not look correct, please add them in alphanumerical > > order as the comment these SET_ISA_EXT_MAP()s requests. Ditto below. > > Agreed. Seems that I did not worked carefully for this part. Or it could be me when rebasing that patch. In any case, it will be fixed with v2 of the patch. Cheers, Samuel. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-27 18:48 ` Conor Dooley 2023-06-27 19:03 ` Hongren (Zenithal) Zheng @ 2023-06-28 10:01 ` Samuel Ortiz 2023-06-28 11:10 ` Conor Dooley 1 sibling, 1 reply; 27+ messages in thread From: Samuel Ortiz @ 2023-06-28 10:01 UTC (permalink / raw) To: Conor Dooley Cc: Evan Green, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > From: "Hongren (Zenithal) Zheng" <i@zenithal.me> > > > > > > This patch parses Zb/Zk related string from DT and > > %s/This patch// > > > > output them in cpuinfo > > > > > > One thing worth noting is that if DT provides zk, > > > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > Please explain why this is okay. > > > > Note that zk is a valid extension name and the current > > > DT binding spec allows this. > > > > > > This patch also changes the logical id of > > > existing multi-letter extensions and adds a statement > > > that instead of logical id compatibility, the order > > > is needed. > > Does it? > > > > There currently lacks a mechanism to merge them when > > > producing cpuinfo. Namely if you provide a riscv,isa > > > "rv64imafdc_zk_zks", the cpuinfo output would be > > > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > > > _zksh_zkt" > > I think this is fine. > > Please re-wrap this all to 72 characters. > > > > > > > Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> > > > Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> > > This is missing your SoB Samuel. > > > > --- > > > arch/riscv/include/asm/hwcap.h | 11 +++++++++++ > > > arch/riscv/kernel/cpu.c | 11 +++++++++++ > > > arch/riscv/kernel/cpufeature.c | 30 ++++++++++++++++++++++++++++++ > > > 3 files changed, 52 insertions(+) > > > > > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > > > index f041bfa7f6a0..b80ca6e77088 100644 > > > --- a/arch/riscv/include/asm/hwcap.h > > > +++ b/arch/riscv/include/asm/hwcap.h > > > @@ -53,6 +53,17 @@ > > > #define RISCV_ISA_EXT_ZICSR 40 > > > #define RISCV_ISA_EXT_ZIFENCEI 41 > > > #define RISCV_ISA_EXT_ZIHPM 42 > > > +#define RISCV_ISA_EXT_ZBC 43 > > > +#define RISCV_ISA_EXT_ZBKB 44 > > > +#define RISCV_ISA_EXT_ZBKC 45 > > > +#define RISCV_ISA_EXT_ZBKX 46 > > > +#define RISCV_ISA_EXT_ZKND 47 > > > +#define RISCV_ISA_EXT_ZKNE 48 > > > +#define RISCV_ISA_EXT_ZKNH 49 > > > +#define RISCV_ISA_EXT_ZKR 50 > > > +#define RISCV_ISA_EXT_ZKSED 51 > > > +#define RISCV_ISA_EXT_ZKSH 52 > > > +#define RISCV_ISA_EXT_ZKT 53 > > > > > > #define RISCV_ISA_EXT_MAX 64 > > > #define RISCV_ISA_EXT_NAME_LEN_MAX 32 > > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > > > index a2fc952318e9..10524322a4c0 100644 > > > --- a/arch/riscv/kernel/cpu.c > > > +++ b/arch/riscv/kernel/cpu.c > > > @@ -215,7 +215,18 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > > > __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), > > > __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > > > __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > > > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > > > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > > > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > > > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > > > __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > > > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > > > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > > > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > > > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > > > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > > > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > > > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > > > __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), > > > __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), > > > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > index bdcf460ea53d..447f853a5a4c 100644 > > > --- a/arch/riscv/kernel/cpufeature.c > > > +++ b/arch/riscv/kernel/cpufeature.c > > > @@ -309,10 +309,40 @@ void __init riscv_fill_hwcap(void) > > > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > > > SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > > > SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > > > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > > > SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > > > + SET_ISA_EXT_MAP("zbkb", RISCV_ISA_EXT_ZBKB); > > This order does not look correct, please add them in alphanumerical > order as the comment these SET_ISA_EXT_MAP()s requests. Ditto below. > > > > + SET_ISA_EXT_MAP("zbkc", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zbks", RISCV_ISA_EXT_ZBKX); > > > > Should "zbks" be "zbkx"? > > > > > SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); > > > SET_ISA_EXT_MAP("zicboz", RISCV_ISA_EXT_ZICBOZ); > > > SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); > > > + SET_ISA_EXT_MAP("zksed", RISCV_ISA_EXT_ZKSED); > > > + SET_ISA_EXT_MAP("zksh", RISCV_ISA_EXT_ZKSH); > > > + SET_ISA_EXT_MAP("zkr", RISCV_ISA_EXT_ZKR); > > > + SET_ISA_EXT_MAP("zkt", RISCV_ISA_EXT_ZKT); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKB); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZBKX); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKND); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNE); > > > + SET_ISA_EXT_MAP("zkn", RISCV_ISA_EXT_ZKNH); > > > + SET_ISA_EXT_MAP("zknd", RISCV_ISA_EXT_ZKND); > > > + SET_ISA_EXT_MAP("zkne", RISCV_ISA_EXT_ZKNE); > > > + SET_ISA_EXT_MAP("zknh", RISCV_ISA_EXT_ZKNH); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKB); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZBKX); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSED); > > > + SET_ISA_EXT_MAP("zks", RISCV_ISA_EXT_ZKSH); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKB); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKC); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZBKX); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKND); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNE); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKNH); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKR); > > > + SET_ISA_EXT_MAP("zk", RISCV_ISA_EXT_ZKT); > > > > It would be nice to consolidate the ones together that search for a > > single string and set multiple bits, though I don't have any super > > elegant ideas for how off the top of my head. > > I've got a refactor of this code in progress, dropping all of these > copy-paste in place of a loop. It certainly looks more elegant than > this, but it will fall over a bit for these "one string matches many > extensions" cases. See here: > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > My immediate thought is to add another element to riscv_isa_ext_data, > that contains "parent" extensions to check for. Should be fairly doable, > I'll whip something up on top of that... Nice, and thanks for the review. Should I wait for your refactor to be merged before pushing this one? Cheers, Samuel. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-28 10:01 ` Samuel Ortiz @ 2023-06-28 11:10 ` Conor Dooley 2023-06-28 12:30 ` Samuel Ortiz ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Conor Dooley @ 2023-06-28 11:10 UTC (permalink / raw) To: Samuel Ortiz Cc: Conor Dooley, Evan Green, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He [-- Attachment #1: Type: text/plain, Size: 1880 bytes --] On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > It would be nice to consolidate the ones together that search for a > > > single string and set multiple bits, though I don't have any super > > > elegant ideas for how off the top of my head. > > > > I've got a refactor of this code in progress, dropping all of these > > copy-paste in place of a loop. It certainly looks more elegant than > > this, but it will fall over a bit for these "one string matches many > > extensions" cases. See here: > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > > My immediate thought is to add another element to riscv_isa_ext_data, > > that contains "parent" extensions to check for. Should be fairly doable, > > I'll whip something up on top of that... > > Nice, and thanks for the review. > Should I wait for your refactor to be merged before pushing this one? I don't know. I think that you should continue on with your series here, and whichever goes in second gets rebased on top of the other. I don't think it makes material difference to review of this patchset as to whether you rebase on top of what I'm working on, so I wouldn't bother until it gets merged. Rather hacky, had less time than expected this morning: https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/commit/?h=riscv-extensions-strings-supersets Clearly there's issues with looping to RISCV_ISA_MAX_SUPERSETS & I just repurposed Zicsr for the sake of testing something in the time I had. Evan, at a high level, does that look more elegant to you, or have I made things worse? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-28 11:10 ` Conor Dooley @ 2023-06-28 12:30 ` Samuel Ortiz 2023-06-28 16:49 ` Conor Dooley 2023-06-28 17:18 ` Evan Green 2 siblings, 0 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-28 12:30 UTC (permalink / raw) To: Conor Dooley Cc: Conor Dooley, Evan Green, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Wed, Jun 28, 2023 at 12:10:11PM +0100, Conor Dooley wrote: > On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > It would be nice to consolidate the ones together that search for a > > > > single string and set multiple bits, though I don't have any super > > > > elegant ideas for how off the top of my head. > > > > > > I've got a refactor of this code in progress, dropping all of these > > > copy-paste in place of a loop. It certainly looks more elegant than > > > this, but it will fall over a bit for these "one string matches many > > > extensions" cases. See here: > > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > > > My immediate thought is to add another element to riscv_isa_ext_data, > > > that contains "parent" extensions to check for. Should be fairly doable, > > > I'll whip something up on top of that... > > > > Nice, and thanks for the review. > > > Should I wait for your refactor to be merged before pushing this one? > > I don't know. I think that you should continue on with your series here, > and whichever goes in second gets rebased on top of the other. Sounds good to me, thanks. Cheers, Samuel. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-28 11:10 ` Conor Dooley 2023-06-28 12:30 ` Samuel Ortiz @ 2023-06-28 16:49 ` Conor Dooley 2023-06-28 17:18 ` Evan Green 2 siblings, 0 replies; 27+ messages in thread From: Conor Dooley @ 2023-06-28 16:49 UTC (permalink / raw) To: Conor Dooley Cc: Samuel Ortiz, Evan Green, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He [-- Attachment #1: Type: text/plain, Size: 8926 bytes --] On Wed, Jun 28, 2023 at 12:10:11PM +0100, Conor Dooley wrote: > On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > It would be nice to consolidate the ones together that search for a > > > > single string and set multiple bits, though I don't have any super > > > > elegant ideas for how off the top of my head. > > > > > > I've got a refactor of this code in progress, dropping all of these > > > copy-paste in place of a loop. It certainly looks more elegant than > > > this, but it will fall over a bit for these "one string matches many > > > extensions" cases. See here: > > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > > > My immediate thought is to add another element to riscv_isa_ext_data, > > > that contains "parent" extensions to check for. Should be fairly doable, > > > I'll whip something up on top of that... > > > > Nice, and thanks for the review. > > > Should I wait for your refactor to be merged before pushing this one? > > I don't know. I think that you should continue on with your series here, > and whichever goes in second gets rebased on top of the other. > I don't think it makes material difference to review of this patchset as > to whether you rebase on top of what I'm working on, so I wouldn't > bother until it gets merged. > > Rather hacky, had less time than expected this morning: > https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/commit/?h=riscv-extensions-strings-supersets > Clearly there's issues with looping to RISCV_ISA_MAX_SUPERSETS & I just > repurposed Zicsr for the sake of testing something in the time I had. > > Evan, at a high level, does that look more elegant to you, or have I made > things worse? Got some more time this afternoon, cleaned it up a bit. On top of what is in https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/log/?h=riscv-extensions-strings IOW, the not-yet-sent v2 of https://lore.kernel.org/all/20230626-provable-angrily-81760e8c3cc6@wendy/ here's some infra for doing superset stuff... Going to send my v2 without this, as there's nothing in tree right now that actually needs this sort of thing. -- >8 -- From 0875e1aa2bf773b53cae02490ebc69e798e491c4 Mon Sep 17 00:00:00 2001 From: Conor Dooley <conor.dooley@microchip.com> Date: Wed, 28 Jun 2023 12:01:40 +0100 Subject: [PATCH] RISC-V: detect extension support from superset extensions Some extensions, for example scalar crypto's Zk extension, are comprised of anumber of sub-extensions that may be implemented independently. Provide some infrastructure for detecting support for an extension where only its superset appears in DT or ACPI. SET_ISA_EXT_MAP() already served little purpose, move the code into an inline function instead, where the code can be reused more easily by the riscv_try_set_ext_from_supersets(). Signed-off-by: Conor Dooley <conor.dooley@microchip.com> --- arch/riscv/include/asm/hwcap.h | 3 + arch/riscv/kernel/cpufeature.c | 107 ++++++++++++++++++++++++++++----- 2 files changed, 96 insertions(+), 14 deletions(-) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index c4d6faa5cdf8..5b41a7aa9ec5 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -73,11 +73,14 @@ unsigned long riscv_get_elf_hwcap(void); +#define RISCV_ISA_MAX_SUPERSETS 1 struct riscv_isa_ext_data { const unsigned int id; const char *name; const char *property; const bool multi_letter; + const unsigned int num_supersets; + const char *supersets[RISCV_ISA_MAX_SUPERSETS]; }; extern const struct riscv_isa_ext_data riscv_isa_ext[]; diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 53b38f6c0562..0d56f4a11a3e 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -104,6 +104,16 @@ static bool riscv_isa_extension_check(int id) .property = #_name, \ .id = _id, \ .multi_letter = _multi, \ + .num_supersets = 0, \ +} + +#define __RISCV_ISA_EXT_DATA_SUBSET(_name, _id, _multi, _num_supersets, ...) { \ + .name = #_name, \ + .property = #_name, \ + .id = _id, \ + .multi_letter = _multi, \ + .num_supersets = _num_supersets, \ + .supersets = {__VA_ARGS__}, \ } /* @@ -180,6 +190,39 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = { const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext); +static inline int __init riscv_try_set_ext(const char *name, const unsigned int bit, + const char *ext, const char *ext_end, + struct riscv_isainfo *isainfo) +{ + if ((ext_end - ext == strlen(name)) && + !strncasecmp(ext, name, strlen(name)) && + riscv_isa_extension_check(bit)) { + set_bit(bit, isainfo->isa); + return 0; + } + + return -EINVAL; +} + +static inline void __init riscv_try_set_ext_from_supersets(struct riscv_isa_ext_data ext_data, + const char *ext, const char *ext_end, + struct riscv_isainfo *isainfo) +{ + for (int i = 0; i < ext_data.num_supersets; i++) { + const char *superset = ext_data.supersets[i]; + const int bit = ext_data.id; + int ret; + + /* + * If the extension that's been found is a superset, there's no + * reason to keep looking for other supersets. + */ + ret = riscv_try_set_ext(superset, bit, ext, ext_end, isainfo); + if (!ret) + return; + } +} + static void __init riscv_parse_isa_string(unsigned long *this_hwcap, struct riscv_isainfo *isainfo, unsigned long *isa2hwcap, const char *isa) { @@ -311,14 +354,6 @@ static void __init riscv_parse_isa_string(unsigned long *this_hwcap, struct risc if (*isa == '_') ++isa; -#define SET_ISA_EXT_MAP(name, bit) \ - do { \ - if ((ext_end - ext == sizeof(name) - 1) && \ - !strncasecmp(ext, name, sizeof(name) - 1) && \ - riscv_isa_extension_check(bit)) \ - set_bit(bit, isainfo->isa); \ - } while (false) \ - if (unlikely(ext_err)) continue; if (!ext_long) { @@ -328,12 +363,27 @@ static void __init riscv_parse_isa_string(unsigned long *this_hwcap, struct risc *this_hwcap |= isa2hwcap[nr]; set_bit(nr, isainfo->isa); } - } else { + for (int i = 0; i < riscv_isa_ext_count; i++) - SET_ISA_EXT_MAP(riscv_isa_ext[i].name, - riscv_isa_ext[i].id); + riscv_try_set_ext_from_supersets(riscv_isa_ext[i], + ext, ext_end, isainfo); + } else { + for (int i = 0; i < riscv_isa_ext_count; i++) { + const char *name = riscv_isa_ext[i].name; + const int bit = riscv_isa_ext[i].id; + int ret; + + ret = riscv_try_set_ext(name, bit, ext, ext_end, isainfo); + + /* + * There's no point checking if the extension that the parser has + * just found is a superset, if it is the extension itself... + */ + if (!ret) + riscv_try_set_ext_from_supersets(riscv_isa_ext[i], + ext, ext_end, isainfo); + } } -#undef SET_ISA_EXT_MAP } } @@ -416,6 +466,28 @@ static void __init riscv_fill_hwcap_from_isa_string(unsigned long *isa2hwcap) acpi_put_table((struct acpi_table_header *)rhct); } +static inline bool riscv_ext_superset_present(struct riscv_isa_ext_data ext_data, + struct device_node *cpu_node) +{ + if (!ext_data.num_supersets) + return false; + + for (int i = 0; i < ext_data.num_supersets; i++) { + const char *superset = ext_data.supersets[i]; + int ret; + + /* + * Once a single superset is found, there's no point looking + * for any other ones. + */ + ret = of_property_match_string(cpu_node,"riscv,isa-extensions", superset); + if (ret >= 0) + return true; + } + + return false; +} + static int __init riscv_fill_hwcap_from_ext_list(unsigned long *isa2hwcap) { unsigned int cpu; @@ -435,8 +507,15 @@ static int __init riscv_fill_hwcap_from_ext_list(unsigned long *isa2hwcap) continue; for (int i = 0; i < riscv_isa_ext_count; i++) { - if (of_property_match_string(cpu_node, "riscv,isa-extensions", - riscv_isa_ext[i].name) < 0) + int ret = of_property_match_string(cpu_node, "riscv,isa-extensions", + riscv_isa_ext[i].name); + + /* + * If the extension itself is not found it could be a + * subset of another extension, so the supersets need to + * be checked for too. + */ + if (ret < 0 && !riscv_ext_superset_present(riscv_isa_ext[i], cpu_node)) continue; if (!riscv_isa_extension_check(riscv_isa_ext[i].id)) -- 2.39.2 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-28 11:10 ` Conor Dooley 2023-06-28 12:30 ` Samuel Ortiz 2023-06-28 16:49 ` Conor Dooley @ 2023-06-28 17:18 ` Evan Green 2023-06-28 17:24 ` Conor Dooley 2 siblings, 1 reply; 27+ messages in thread From: Evan Green @ 2023-06-28 17:18 UTC (permalink / raw) To: Conor Dooley Cc: Samuel Ortiz, Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He On Wed, Jun 28, 2023 at 4:10 AM Conor Dooley <conor.dooley@microchip.com> wrote: > > On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > It would be nice to consolidate the ones together that search for a > > > > single string and set multiple bits, though I don't have any super > > > > elegant ideas for how off the top of my head. > > > > > > I've got a refactor of this code in progress, dropping all of these > > > copy-paste in place of a loop. It certainly looks more elegant than > > > this, but it will fall over a bit for these "one string matches many > > > extensions" cases. See here: > > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > > > My immediate thought is to add another element to riscv_isa_ext_data, > > > that contains "parent" extensions to check for. Should be fairly doable, > > > I'll whip something up on top of that... > > > > Nice, and thanks for the review. > > > Should I wait for your refactor to be merged before pushing this one? > > I don't know. I think that you should continue on with your series here, > and whichever goes in second gets rebased on top of the other. > I don't think it makes material difference to review of this patchset as > to whether you rebase on top of what I'm working on, so I wouldn't > bother until it gets merged. > > Rather hacky, had less time than expected this morning: > https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/commit/?h=riscv-extensions-strings-supersets > Clearly there's issues with looping to RISCV_ISA_MAX_SUPERSETS & I just > repurposed Zicsr for the sake of testing something in the time I had. > > Evan, at a high level, does that look more elegant to you, or have I made > things worse? > I see what you're going for at least. It's unfortunate that when someone bumps up RISCV_ISA_MAX_SUPERSETS it squares the whole array. Another way to go might be to define the elements in a separate array, like: unsigned int riscv_zks_exts[] = { RISCV_ISA_EXT_ZBKB, RISCV_ISA_EXT_ZBKC, .... }; then the macro entry looks like: SET_ISA_EXT_MAP_MULTI("zks", riscv_zks_exts), where the SET_ISA_EXT_MAP_MULTI() could use ARRAY_SIZE() to stash both the pointer to the array and the number of elements. -Evan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-28 17:18 ` Evan Green @ 2023-06-28 17:24 ` Conor Dooley 2023-07-03 17:39 ` Conor Dooley 0 siblings, 1 reply; 27+ messages in thread From: Conor Dooley @ 2023-06-28 17:24 UTC (permalink / raw) To: Evan Green Cc: Conor Dooley, Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He [-- Attachment #1: Type: text/plain, Size: 2952 bytes --] On Wed, Jun 28, 2023 at 10:18:34AM -0700, Evan Green wrote: > On Wed, Jun 28, 2023 at 4:10 AM Conor Dooley <conor.dooley@microchip.com> wrote: > > > > On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > > > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > > It would be nice to consolidate the ones together that search for a > > > > > single string and set multiple bits, though I don't have any super > > > > > elegant ideas for how off the top of my head. > > > > > > > > I've got a refactor of this code in progress, dropping all of these > > > > copy-paste in place of a loop. It certainly looks more elegant than > > > > this, but it will fall over a bit for these "one string matches many > > > > extensions" cases. See here: > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > > > > My immediate thought is to add another element to riscv_isa_ext_data, > > > > that contains "parent" extensions to check for. Should be fairly doable, > > > > I'll whip something up on top of that... > > > > > > Nice, and thanks for the review. > > > > > Should I wait for your refactor to be merged before pushing this one? > > > > I don't know. I think that you should continue on with your series here, > > and whichever goes in second gets rebased on top of the other. > > I don't think it makes material difference to review of this patchset as > > to whether you rebase on top of what I'm working on, so I wouldn't > > bother until it gets merged. > > > > Rather hacky, had less time than expected this morning: > > https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/commit/?h=riscv-extensions-strings-supersets > > Clearly there's issues with looping to RISCV_ISA_MAX_SUPERSETS & I just > > repurposed Zicsr for the sake of testing something in the time I had. > > > > Evan, at a high level, does that look more elegant to you, or have I made > > things worse? > > > > I see what you're going for at least. It's unfortunate that when > someone bumps up RISCV_ISA_MAX_SUPERSETS it squares the whole array. > Another way to go might be to define the elements in a separate array, > like: > > unsigned int riscv_zks_exts[] = { > RISCV_ISA_EXT_ZBKB, > RISCV_ISA_EXT_ZBKC, > .... > }; > > then the macro entry looks like: > > SET_ISA_EXT_MAP_MULTI("zks", riscv_zks_exts), > > where the SET_ISA_EXT_MAP_MULTI() could use ARRAY_SIZE() to stash both > the pointer to the array and the number of elements. Yup, I like the sound of that. I like the variadic stuff as it'd not require defining a bunch of sub-arrays of supersets. I guess if it grows too badly, we can just dump it off into another file or w/e. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2023-06-28 17:24 ` Conor Dooley @ 2023-07-03 17:39 ` Conor Dooley 0 siblings, 0 replies; 27+ messages in thread From: Conor Dooley @ 2023-07-03 17:39 UTC (permalink / raw) To: Evan Green Cc: Conor Dooley, Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, Hongren (Zenithal) Zheng, linux, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Guo Ren, Atish Patra, Björn Töpel, Jiatai He [-- Attachment #1: Type: text/plain, Size: 3627 bytes --] On Wed, Jun 28, 2023 at 06:24:40PM +0100, Conor Dooley wrote: > On Wed, Jun 28, 2023 at 10:18:34AM -0700, Evan Green wrote: > > On Wed, Jun 28, 2023 at 4:10 AM Conor Dooley <conor.dooley@microchip.com> wrote: > > > > > > On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > > > > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > > > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > > > > On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > > > > > > > > It would be nice to consolidate the ones together that search for a > > > > > > single string and set multiple bits, though I don't have any super > > > > > > elegant ideas for how off the top of my head. > > > > > > > > > > I've got a refactor of this code in progress, dropping all of these > > > > > copy-paste in place of a loop. It certainly looks more elegant than > > > > > this, but it will fall over a bit for these "one string matches many > > > > > extensions" cases. See here: > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thieving-jockstrap-d35d20b535c5@wendy/ > > > > > My immediate thought is to add another element to riscv_isa_ext_data, > > > > > that contains "parent" extensions to check for. Should be fairly doable, > > > > > I'll whip something up on top of that... > > > > > > > > Nice, and thanks for the review. > > > > > > > Should I wait for your refactor to be merged before pushing this one? > > > > > > I don't know. I think that you should continue on with your series here, > > > and whichever goes in second gets rebased on top of the other. > > > I don't think it makes material difference to review of this patchset as > > > to whether you rebase on top of what I'm working on, so I wouldn't > > > bother until it gets merged. > > > > > > Rather hacky, had less time than expected this morning: > > > https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/commit/?h=riscv-extensions-strings-supersets > > > Clearly there's issues with looping to RISCV_ISA_MAX_SUPERSETS & I just > > > repurposed Zicsr for the sake of testing something in the time I had. > > > > > > Evan, at a high level, does that look more elegant to you, or have I made > > > things worse? > > > > > > > I see what you're going for at least. It's unfortunate that when > > someone bumps up RISCV_ISA_MAX_SUPERSETS it squares the whole array. > > Another way to go might be to define the elements in a separate array, > > like: > > > > unsigned int riscv_zks_exts[] = { > > RISCV_ISA_EXT_ZBKB, > > RISCV_ISA_EXT_ZBKC, > > .... > > }; > > > > then the macro entry looks like: > > > > SET_ISA_EXT_MAP_MULTI("zks", riscv_zks_exts), > > > > where the SET_ISA_EXT_MAP_MULTI() could use ARRAY_SIZE() to stash both > > the pointer to the array and the number of elements. > > Yup, I like the sound of that. I like the variadic stuff as it'd not > require defining a bunch of sub-arrays of supersets. I guess if it grows > too badly, we can just dump it off into another file or w/e. Also, I realised the other day that I had a bug in my series - I was using "name" to read the property, not "property", which is what required the extra "supersets" property. The simplest thing to do actually seems to be to expand the "property" member to an array of strings named "properties", rather than introducing a "supersets" or similar. Perhaps I am forgetting a good reason for why I had it split, but I'll give it a whirl and see what I think... Cheers, Conor. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <97a7d701-3b48-252e-6d78-ef3d0e7f8f03@web.de>]
* Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT [not found] ` <97a7d701-3b48-252e-6d78-ef3d0e7f8f03@web.de> @ 2023-06-28 12:29 ` Samuel Ortiz 0 siblings, 0 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-28 12:29 UTC (permalink / raw) To: Markus Elfring Cc: Hongren Zheng, linux-riscv, kernel-janitors, Albert Ou, Jiatai He, Palmer Dabbelt, Paul Walmsley, LKML, linux, Andrew Jones, Anup Patel, Atish Patra, Björn Töpel, Conor Dooley, Evan Green, Guo Ren, Heiko Stübner, Stefan O'Rear On Wed, Jun 28, 2023 at 01:21:01PM +0200, Markus Elfring wrote: > … > > This patch also changes the logical id of > … > > Does such a wording really fit to the known requirement “Solve only one problem per patch.”? That comment is inaccurate anyways. I removed it from v2 of the patch set. Cheers, Samuel. > See also: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.4#n81 > > > Please choose an imperative change suggestion. > > Regards, > Markus ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-06-27 14:37 [PATCH 0/3] RISC-V: archrandom support Samuel Ortiz 2023-06-27 14:37 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Samuel Ortiz @ 2023-06-27 14:37 ` Samuel Ortiz 2023-06-27 18:13 ` Evan Green 2023-06-28 0:34 ` Stefan O'Rear 2023-06-27 14:37 ` [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available Samuel Ortiz 2 siblings, 2 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-27 14:37 UTC (permalink / raw) To: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: Samuel Ortiz, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green Zbc was missing from a previous Bit-Manipulation extension hwprobe patch. Add all scalar crypto extensions bits, and define a macro for setting the hwprobe key/pair in a more readable way. Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> --- Documentation/riscv/hwprobe.rst | 33 ++++++++++++++++++++++++ arch/riscv/include/uapi/asm/hwprobe.h | 11 ++++++++ arch/riscv/kernel/sys_riscv.c | 36 ++++++++++++++++----------- 3 files changed, 66 insertions(+), 14 deletions(-) diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst index 19165ebd82ba..3177550106e0 100644 --- a/Documentation/riscv/hwprobe.rst +++ b/Documentation/riscv/hwprobe.rst @@ -72,11 +72,44 @@ The following keys are defined: extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined + in version 1.0 of the Bit-Manipulation ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZBC`: The Zbc extension is supported, as defined in version 1.0 of the Bit-Manipulation ISA extensions. * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined in version 1.0 of the Bit-Manipulation ISA extensions. + * :c:macro:`RISCV_HWPROBE_EXT_ZBKB`: The Zbkb extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZBKC`: The Zbkc extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZBKX`: The Zbkx extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKND`: The Zknd extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKNE`: The Zkne extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKNH`: The Zknh extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKR`: The Zkr extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKSED`: The Zksed extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKSH`: The Zksh extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + + * :c:macro:`RISCV_HWPROBE_EXT_ZKT`: The Zkt extension is supported, as defined + in version 1.0 of the Scalar Cryptography ISA extensions. + * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance information about the selected set of processors. diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h index 006bfb48343d..8357052061b3 100644 --- a/arch/riscv/include/uapi/asm/hwprobe.h +++ b/arch/riscv/include/uapi/asm/hwprobe.h @@ -29,6 +29,17 @@ struct riscv_hwprobe { #define RISCV_HWPROBE_EXT_ZBA (1 << 3) #define RISCV_HWPROBE_EXT_ZBB (1 << 4) #define RISCV_HWPROBE_EXT_ZBS (1 << 5) +#define RISCV_HWPROBE_EXT_ZBC (1 << 6) +#define RISCV_HWPROBE_EXT_ZBKB (1 << 7) +#define RISCV_HWPROBE_EXT_ZBKC (1 << 8) +#define RISCV_HWPROBE_EXT_ZBKX (1 << 9) +#define RISCV_HWPROBE_EXT_ZKND (1 << 10) +#define RISCV_HWPROBE_EXT_ZKNE (1 << 11) +#define RISCV_HWPROBE_EXT_ZKNH (1 << 12) +#define RISCV_HWPROBE_EXT_ZKR (1 << 13) +#define RISCV_HWPROBE_EXT_ZKSED (1 << 14) +#define RISCV_HWPROBE_EXT_ZKSH (1 << 15) +#define RISCV_HWPROBE_EXT_ZKT (1 << 16) #define RISCV_HWPROBE_KEY_CPUPERF_0 5 #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0) #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0) diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c index 26ef5526bfb4..df15926196b6 100644 --- a/arch/riscv/kernel/sys_riscv.c +++ b/arch/riscv/kernel/sys_riscv.c @@ -145,20 +145,28 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair, for_each_cpu(cpu, cpus) { struct riscv_isainfo *isainfo = &hart_isa[cpu]; - if (riscv_isa_extension_available(isainfo->isa, ZBA)) - pair->value |= RISCV_HWPROBE_EXT_ZBA; - else - missing |= RISCV_HWPROBE_EXT_ZBA; - - if (riscv_isa_extension_available(isainfo->isa, ZBB)) - pair->value |= RISCV_HWPROBE_EXT_ZBB; - else - missing |= RISCV_HWPROBE_EXT_ZBB; - - if (riscv_isa_extension_available(isainfo->isa, ZBS)) - pair->value |= RISCV_HWPROBE_EXT_ZBS; - else - missing |= RISCV_HWPROBE_EXT_ZBS; +#define SET_HWPROBE_EXT_PAIR(ext) \ + do { \ + if (riscv_isa_extension_available(isainfo->isa, ext)) \ + pair->value |= RISCV_HWPROBE_EXT_## ext; \ + else \ + missing |= RISCV_HWPROBE_EXT_## ext; \ + } while (false) \ + + SET_HWPROBE_EXT_PAIR(ZBA); + SET_HWPROBE_EXT_PAIR(ZBB); + SET_HWPROBE_EXT_PAIR(ZBC); + SET_HWPROBE_EXT_PAIR(ZBS); + SET_HWPROBE_EXT_PAIR(ZBKB); + SET_HWPROBE_EXT_PAIR(ZBKC); + SET_HWPROBE_EXT_PAIR(ZBKX); + SET_HWPROBE_EXT_PAIR(ZKND); + SET_HWPROBE_EXT_PAIR(ZKNE); + SET_HWPROBE_EXT_PAIR(ZKNH); + SET_HWPROBE_EXT_PAIR(ZKR); + SET_HWPROBE_EXT_PAIR(ZKSED); + SET_HWPROBE_EXT_PAIR(ZKSH); + SET_HWPROBE_EXT_PAIR(ZKT); } /* Now turn off reporting features if any CPU is missing it. */ -- 2.41.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-06-27 14:37 ` [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions Samuel Ortiz @ 2023-06-27 18:13 ` Evan Green 2023-06-28 0:34 ` Stefan O'Rear 1 sibling, 0 replies; 27+ messages in thread From: Evan Green @ 2023-06-27 18:13 UTC (permalink / raw) To: Samuel Ortiz Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel On Tue, Jun 27, 2023 at 7:38 AM Samuel Ortiz <sameo@rivosinc.com> wrote: > > Zbc was missing from a previous Bit-Manipulation extension hwprobe > patch. > > Add all scalar crypto extensions bits, and define a macro for setting > the hwprobe key/pair in a more readable way. > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> Reviewed-by: Evan Green <evan@rivosinc.com> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-06-27 14:37 ` [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions Samuel Ortiz 2023-06-27 18:13 ` Evan Green @ 2023-06-28 0:34 ` Stefan O'Rear 2023-06-28 10:04 ` Samuel Ortiz 1 sibling, 1 reply; 27+ messages in thread From: Stefan O'Rear @ 2023-06-28 0:34 UTC (permalink / raw) To: Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green On Tue, Jun 27, 2023, at 10:37 AM, Samuel Ortiz wrote: > Zbc was missing from a previous Bit-Manipulation extension hwprobe > patch. > > Add all scalar crypto extensions bits, and define a macro for setting > the hwprobe key/pair in a more readable way. > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > --- > Documentation/riscv/hwprobe.rst | 33 ++++++++++++++++++++++++ > arch/riscv/include/uapi/asm/hwprobe.h | 11 ++++++++ > arch/riscv/kernel/sys_riscv.c | 36 ++++++++++++++++----------- > 3 files changed, 66 insertions(+), 14 deletions(-) > > diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst > index 19165ebd82ba..3177550106e0 100644 > --- a/Documentation/riscv/hwprobe.rst > +++ b/Documentation/riscv/hwprobe.rst > @@ -72,11 +72,44 @@ The following keys are defined: > extensions. > > * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, > as defined > + in version 1.0 of the Bit-Manipulation ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZBC`: The Zbc extension is supported, > as defined > in version 1.0 of the Bit-Manipulation ISA extensions. > > * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, > as defined > in version 1.0 of the Bit-Manipulation ISA extensions. > > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKB`: The Zbkb extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKC`: The Zbkc extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKX`: The Zbkx extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKND`: The Zknd extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNE`: The Zkne extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNH`: The Zknh extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKR`: The Zkr extension is supported, > as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSED`: The Zksed extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSH`: The Zksh extension is > supported, as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > + * :c:macro:`RISCV_HWPROBE_EXT_ZKT`: The Zkt extension is supported, > as defined > + in version 1.0 of the Scalar Cryptography ISA extensions. > + > * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains > performance > information about the selected set of processors. > > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h > b/arch/riscv/include/uapi/asm/hwprobe.h > index 006bfb48343d..8357052061b3 100644 > --- a/arch/riscv/include/uapi/asm/hwprobe.h > +++ b/arch/riscv/include/uapi/asm/hwprobe.h > @@ -29,6 +29,17 @@ struct riscv_hwprobe { > #define RISCV_HWPROBE_EXT_ZBA (1 << 3) > #define RISCV_HWPROBE_EXT_ZBB (1 << 4) > #define RISCV_HWPROBE_EXT_ZBS (1 << 5) > +#define RISCV_HWPROBE_EXT_ZBC (1 << 6) > +#define RISCV_HWPROBE_EXT_ZBKB (1 << 7) > +#define RISCV_HWPROBE_EXT_ZBKC (1 << 8) > +#define RISCV_HWPROBE_EXT_ZBKX (1 << 9) > +#define RISCV_HWPROBE_EXT_ZKND (1 << 10) > +#define RISCV_HWPROBE_EXT_ZKNE (1 << 11) > +#define RISCV_HWPROBE_EXT_ZKNH (1 << 12) > +#define RISCV_HWPROBE_EXT_ZKR (1 << 13) > +#define RISCV_HWPROBE_EXT_ZKSED (1 << 14) > +#define RISCV_HWPROBE_EXT_ZKSH (1 << 15) > +#define RISCV_HWPROBE_EXT_ZKT (1 << 16) > #define RISCV_HWPROBE_KEY_CPUPERF_0 5 > #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0) > #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0) > diff --git a/arch/riscv/kernel/sys_riscv.c > b/arch/riscv/kernel/sys_riscv.c > index 26ef5526bfb4..df15926196b6 100644 > --- a/arch/riscv/kernel/sys_riscv.c > +++ b/arch/riscv/kernel/sys_riscv.c > @@ -145,20 +145,28 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe > *pair, > for_each_cpu(cpu, cpus) { > struct riscv_isainfo *isainfo = &hart_isa[cpu]; > > - if (riscv_isa_extension_available(isainfo->isa, ZBA)) > - pair->value |= RISCV_HWPROBE_EXT_ZBA; > - else > - missing |= RISCV_HWPROBE_EXT_ZBA; > - > - if (riscv_isa_extension_available(isainfo->isa, ZBB)) > - pair->value |= RISCV_HWPROBE_EXT_ZBB; > - else > - missing |= RISCV_HWPROBE_EXT_ZBB; > - > - if (riscv_isa_extension_available(isainfo->isa, ZBS)) > - pair->value |= RISCV_HWPROBE_EXT_ZBS; > - else > - missing |= RISCV_HWPROBE_EXT_ZBS; > +#define SET_HWPROBE_EXT_PAIR(ext) \ > + do { \ > + if (riscv_isa_extension_available(isainfo->isa, ext)) \ > + pair->value |= RISCV_HWPROBE_EXT_## ext; \ > + else \ > + missing |= RISCV_HWPROBE_EXT_## ext; \ > + } while (false) \ > + > + SET_HWPROBE_EXT_PAIR(ZBA); > + SET_HWPROBE_EXT_PAIR(ZBB); > + SET_HWPROBE_EXT_PAIR(ZBC); > + SET_HWPROBE_EXT_PAIR(ZBS); > + SET_HWPROBE_EXT_PAIR(ZBKB); > + SET_HWPROBE_EXT_PAIR(ZBKC); > + SET_HWPROBE_EXT_PAIR(ZBKX); > + SET_HWPROBE_EXT_PAIR(ZKND); > + SET_HWPROBE_EXT_PAIR(ZKNE); > + SET_HWPROBE_EXT_PAIR(ZKNH); > + SET_HWPROBE_EXT_PAIR(ZKR); Does the presence of a HWPROBE_EXT bit imply that userspace software can actually directly use the described feature? If so, we should probably not set ZKR unless mseccfg.USEED=1. -s > + SET_HWPROBE_EXT_PAIR(ZKSED); > + SET_HWPROBE_EXT_PAIR(ZKSH); > + SET_HWPROBE_EXT_PAIR(ZKT); > } > > /* Now turn off reporting features if any CPU is missing it. */ > -- > 2.41.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-06-28 0:34 ` Stefan O'Rear @ 2023-06-28 10:04 ` Samuel Ortiz 2023-06-28 13:25 ` Stefan O'Rear 0 siblings, 1 reply; 27+ messages in thread From: Samuel Ortiz @ 2023-06-28 10:04 UTC (permalink / raw) To: Stefan O'Rear Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green On Tue, Jun 27, 2023 at 08:34:20PM -0400, Stefan O'Rear wrote: > On Tue, Jun 27, 2023, at 10:37 AM, Samuel Ortiz wrote: > > Zbc was missing from a previous Bit-Manipulation extension hwprobe > > patch. > > > > Add all scalar crypto extensions bits, and define a macro for setting > > the hwprobe key/pair in a more readable way. > > > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > > --- > > Documentation/riscv/hwprobe.rst | 33 ++++++++++++++++++++++++ > > arch/riscv/include/uapi/asm/hwprobe.h | 11 ++++++++ > > arch/riscv/kernel/sys_riscv.c | 36 ++++++++++++++++----------- > > 3 files changed, 66 insertions(+), 14 deletions(-) > > > > diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst > > index 19165ebd82ba..3177550106e0 100644 > > --- a/Documentation/riscv/hwprobe.rst > > +++ b/Documentation/riscv/hwprobe.rst > > @@ -72,11 +72,44 @@ The following keys are defined: > > extensions. > > > > * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, > > as defined > > + in version 1.0 of the Bit-Manipulation ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZBC`: The Zbc extension is supported, > > as defined > > in version 1.0 of the Bit-Manipulation ISA extensions. > > > > * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, > > as defined > > in version 1.0 of the Bit-Manipulation ISA extensions. > > > > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKB`: The Zbkb extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKC`: The Zbkc extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKX`: The Zbkx extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKND`: The Zknd extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNE`: The Zkne extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNH`: The Zknh extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKR`: The Zkr extension is supported, > > as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSED`: The Zksed extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSH`: The Zksh extension is > > supported, as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > + * :c:macro:`RISCV_HWPROBE_EXT_ZKT`: The Zkt extension is supported, > > as defined > > + in version 1.0 of the Scalar Cryptography ISA extensions. > > + > > * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains > > performance > > information about the selected set of processors. > > > > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h > > b/arch/riscv/include/uapi/asm/hwprobe.h > > index 006bfb48343d..8357052061b3 100644 > > --- a/arch/riscv/include/uapi/asm/hwprobe.h > > +++ b/arch/riscv/include/uapi/asm/hwprobe.h > > @@ -29,6 +29,17 @@ struct riscv_hwprobe { > > #define RISCV_HWPROBE_EXT_ZBA (1 << 3) > > #define RISCV_HWPROBE_EXT_ZBB (1 << 4) > > #define RISCV_HWPROBE_EXT_ZBS (1 << 5) > > +#define RISCV_HWPROBE_EXT_ZBC (1 << 6) > > +#define RISCV_HWPROBE_EXT_ZBKB (1 << 7) > > +#define RISCV_HWPROBE_EXT_ZBKC (1 << 8) > > +#define RISCV_HWPROBE_EXT_ZBKX (1 << 9) > > +#define RISCV_HWPROBE_EXT_ZKND (1 << 10) > > +#define RISCV_HWPROBE_EXT_ZKNE (1 << 11) > > +#define RISCV_HWPROBE_EXT_ZKNH (1 << 12) > > +#define RISCV_HWPROBE_EXT_ZKR (1 << 13) > > +#define RISCV_HWPROBE_EXT_ZKSED (1 << 14) > > +#define RISCV_HWPROBE_EXT_ZKSH (1 << 15) > > +#define RISCV_HWPROBE_EXT_ZKT (1 << 16) > > #define RISCV_HWPROBE_KEY_CPUPERF_0 5 > > #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0) > > #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0) > > diff --git a/arch/riscv/kernel/sys_riscv.c > > b/arch/riscv/kernel/sys_riscv.c > > index 26ef5526bfb4..df15926196b6 100644 > > --- a/arch/riscv/kernel/sys_riscv.c > > +++ b/arch/riscv/kernel/sys_riscv.c > > @@ -145,20 +145,28 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe > > *pair, > > for_each_cpu(cpu, cpus) { > > struct riscv_isainfo *isainfo = &hart_isa[cpu]; > > > > - if (riscv_isa_extension_available(isainfo->isa, ZBA)) > > - pair->value |= RISCV_HWPROBE_EXT_ZBA; > > - else > > - missing |= RISCV_HWPROBE_EXT_ZBA; > > - > > - if (riscv_isa_extension_available(isainfo->isa, ZBB)) > > - pair->value |= RISCV_HWPROBE_EXT_ZBB; > > - else > > - missing |= RISCV_HWPROBE_EXT_ZBB; > > - > > - if (riscv_isa_extension_available(isainfo->isa, ZBS)) > > - pair->value |= RISCV_HWPROBE_EXT_ZBS; > > - else > > - missing |= RISCV_HWPROBE_EXT_ZBS; > > +#define SET_HWPROBE_EXT_PAIR(ext) \ > > + do { \ > > + if (riscv_isa_extension_available(isainfo->isa, ext)) \ > > + pair->value |= RISCV_HWPROBE_EXT_## ext; \ > > + else \ > > + missing |= RISCV_HWPROBE_EXT_## ext; \ > > + } while (false) \ > > + > > + SET_HWPROBE_EXT_PAIR(ZBA); > > + SET_HWPROBE_EXT_PAIR(ZBB); > > + SET_HWPROBE_EXT_PAIR(ZBC); > > + SET_HWPROBE_EXT_PAIR(ZBS); > > + SET_HWPROBE_EXT_PAIR(ZBKB); > > + SET_HWPROBE_EXT_PAIR(ZBKC); > > + SET_HWPROBE_EXT_PAIR(ZBKX); > > + SET_HWPROBE_EXT_PAIR(ZKND); > > + SET_HWPROBE_EXT_PAIR(ZKNE); > > + SET_HWPROBE_EXT_PAIR(ZKNH); > > + SET_HWPROBE_EXT_PAIR(ZKR); > > Does the presence of a HWPROBE_EXT bit imply that userspace software can > actually directly use the described feature? If so, we should probably > not set ZKR unless mseccfg.USEED=1. mseccfg is MRW, so only accessible from M-mode only afaiu. So I don't think we would be able to check that from Linux in S-mode. Cheers, Samuel. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-06-28 10:04 ` Samuel Ortiz @ 2023-06-28 13:25 ` Stefan O'Rear 2023-07-10 7:59 ` Samuel Ortiz 0 siblings, 1 reply; 27+ messages in thread From: Stefan O'Rear @ 2023-06-28 13:25 UTC (permalink / raw) To: Samuel Ortiz Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green On Wed, Jun 28, 2023, at 6:04 AM, Samuel Ortiz wrote: > On Tue, Jun 27, 2023 at 08:34:20PM -0400, Stefan O'Rear wrote: >> On Tue, Jun 27, 2023, at 10:37 AM, Samuel Ortiz wrote: >> > Zbc was missing from a previous Bit-Manipulation extension hwprobe >> > patch. >> > >> > Add all scalar crypto extensions bits, and define a macro for setting >> > the hwprobe key/pair in a more readable way. >> > >> > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> >> > --- >> > Documentation/riscv/hwprobe.rst | 33 ++++++++++++++++++++++++ >> > arch/riscv/include/uapi/asm/hwprobe.h | 11 ++++++++ >> > arch/riscv/kernel/sys_riscv.c | 36 ++++++++++++++++----------- >> > 3 files changed, 66 insertions(+), 14 deletions(-) >> > >> > diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst >> > index 19165ebd82ba..3177550106e0 100644 >> > --- a/Documentation/riscv/hwprobe.rst >> > +++ b/Documentation/riscv/hwprobe.rst >> > @@ -72,11 +72,44 @@ The following keys are defined: >> > extensions. >> > >> > * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, >> > as defined >> > + in version 1.0 of the Bit-Manipulation ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBC`: The Zbc extension is supported, >> > as defined >> > in version 1.0 of the Bit-Manipulation ISA extensions. >> > >> > * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, >> > as defined >> > in version 1.0 of the Bit-Manipulation ISA extensions. >> > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKB`: The Zbkb extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKC`: The Zbkc extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKX`: The Zbkx extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKND`: The Zknd extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNE`: The Zkne extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNH`: The Zknh extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKR`: The Zkr extension is supported, >> > as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSED`: The Zksed extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSH`: The Zksh extension is >> > supported, as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKT`: The Zkt extension is supported, >> > as defined >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> > + >> > * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains >> > performance >> > information about the selected set of processors. >> > >> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h >> > b/arch/riscv/include/uapi/asm/hwprobe.h >> > index 006bfb48343d..8357052061b3 100644 >> > --- a/arch/riscv/include/uapi/asm/hwprobe.h >> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h >> > @@ -29,6 +29,17 @@ struct riscv_hwprobe { >> > #define RISCV_HWPROBE_EXT_ZBA (1 << 3) >> > #define RISCV_HWPROBE_EXT_ZBB (1 << 4) >> > #define RISCV_HWPROBE_EXT_ZBS (1 << 5) >> > +#define RISCV_HWPROBE_EXT_ZBC (1 << 6) >> > +#define RISCV_HWPROBE_EXT_ZBKB (1 << 7) >> > +#define RISCV_HWPROBE_EXT_ZBKC (1 << 8) >> > +#define RISCV_HWPROBE_EXT_ZBKX (1 << 9) >> > +#define RISCV_HWPROBE_EXT_ZKND (1 << 10) >> > +#define RISCV_HWPROBE_EXT_ZKNE (1 << 11) >> > +#define RISCV_HWPROBE_EXT_ZKNH (1 << 12) >> > +#define RISCV_HWPROBE_EXT_ZKR (1 << 13) >> > +#define RISCV_HWPROBE_EXT_ZKSED (1 << 14) >> > +#define RISCV_HWPROBE_EXT_ZKSH (1 << 15) >> > +#define RISCV_HWPROBE_EXT_ZKT (1 << 16) >> > #define RISCV_HWPROBE_KEY_CPUPERF_0 5 >> > #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0) >> > #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0) >> > diff --git a/arch/riscv/kernel/sys_riscv.c >> > b/arch/riscv/kernel/sys_riscv.c >> > index 26ef5526bfb4..df15926196b6 100644 >> > --- a/arch/riscv/kernel/sys_riscv.c >> > +++ b/arch/riscv/kernel/sys_riscv.c >> > @@ -145,20 +145,28 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe >> > *pair, >> > for_each_cpu(cpu, cpus) { >> > struct riscv_isainfo *isainfo = &hart_isa[cpu]; >> > >> > - if (riscv_isa_extension_available(isainfo->isa, ZBA)) >> > - pair->value |= RISCV_HWPROBE_EXT_ZBA; >> > - else >> > - missing |= RISCV_HWPROBE_EXT_ZBA; >> > - >> > - if (riscv_isa_extension_available(isainfo->isa, ZBB)) >> > - pair->value |= RISCV_HWPROBE_EXT_ZBB; >> > - else >> > - missing |= RISCV_HWPROBE_EXT_ZBB; >> > - >> > - if (riscv_isa_extension_available(isainfo->isa, ZBS)) >> > - pair->value |= RISCV_HWPROBE_EXT_ZBS; >> > - else >> > - missing |= RISCV_HWPROBE_EXT_ZBS; >> > +#define SET_HWPROBE_EXT_PAIR(ext) \ >> > + do { \ >> > + if (riscv_isa_extension_available(isainfo->isa, ext)) \ >> > + pair->value |= RISCV_HWPROBE_EXT_## ext; \ >> > + else \ >> > + missing |= RISCV_HWPROBE_EXT_## ext; \ >> > + } while (false) \ >> > + >> > + SET_HWPROBE_EXT_PAIR(ZBA); >> > + SET_HWPROBE_EXT_PAIR(ZBB); >> > + SET_HWPROBE_EXT_PAIR(ZBC); >> > + SET_HWPROBE_EXT_PAIR(ZBS); >> > + SET_HWPROBE_EXT_PAIR(ZBKB); >> > + SET_HWPROBE_EXT_PAIR(ZBKC); >> > + SET_HWPROBE_EXT_PAIR(ZBKX); >> > + SET_HWPROBE_EXT_PAIR(ZKND); >> > + SET_HWPROBE_EXT_PAIR(ZKNE); >> > + SET_HWPROBE_EXT_PAIR(ZKNH); >> > + SET_HWPROBE_EXT_PAIR(ZKR); >> >> Does the presence of a HWPROBE_EXT bit imply that userspace software can >> actually directly use the described feature? If so, we should probably >> not set ZKR unless mseccfg.USEED=1. > > mseccfg is MRW, so only accessible from M-mode only afaiu. So I don't > think we would be able to check that from Linux in S-mode. Check directly, no, but your patch already makes the assumption that mseccfg.SSEED=1 if zkr is present in the device tree. Which is fine as long as that contract is documented somewhere (presumably, the device tree binding; some of the language in the RVA22U64 profile spec implies USEED=0, but linux does not require profiles and they don't exist for rv32). If we want U-mode behavior to be discoverable and/or predictable, we have three good options: Simplest: Document that we expect USEED=0 or USEED=1. Set zkr appropriately in hwprobe. Most flexible: Work with the SBI people to add a SBI_EXT_FWFEATURE for USEED, as well as defining the value on kernel entry. Expose this via hwprobe and a new prctl. Most robust: Add an illegal instruction handler for CSR_SEED that grabs 16 bits from the kernel entropy pool. Expose zkr in hwprobe unconditionally. -s > Cheers, > Samuel. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-06-28 13:25 ` Stefan O'Rear @ 2023-07-10 7:59 ` Samuel Ortiz 2023-07-12 5:54 ` Stefan O'Rear 0 siblings, 1 reply; 27+ messages in thread From: Samuel Ortiz @ 2023-07-10 7:59 UTC (permalink / raw) To: Stefan O'Rear Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green On Wed, Jun 28, 2023 at 09:25:02AM -0400, Stefan O'Rear wrote: > On Wed, Jun 28, 2023, at 6:04 AM, Samuel Ortiz wrote: > > On Tue, Jun 27, 2023 at 08:34:20PM -0400, Stefan O'Rear wrote: > >> On Tue, Jun 27, 2023, at 10:37 AM, Samuel Ortiz wrote: > >> > Zbc was missing from a previous Bit-Manipulation extension hwprobe > >> > patch. > >> > > >> > Add all scalar crypto extensions bits, and define a macro for setting > >> > the hwprobe key/pair in a more readable way. > >> > > >> > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > >> > --- > >> > Documentation/riscv/hwprobe.rst | 33 ++++++++++++++++++++++++ > >> > arch/riscv/include/uapi/asm/hwprobe.h | 11 ++++++++ > >> > arch/riscv/kernel/sys_riscv.c | 36 ++++++++++++++++----------- > >> > 3 files changed, 66 insertions(+), 14 deletions(-) > >> > > >> > diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst > >> > index 19165ebd82ba..3177550106e0 100644 > >> > --- a/Documentation/riscv/hwprobe.rst > >> > +++ b/Documentation/riscv/hwprobe.rst > >> > @@ -72,11 +72,44 @@ The following keys are defined: > >> > extensions. > >> > > >> > * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, > >> > as defined > >> > + in version 1.0 of the Bit-Manipulation ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBC`: The Zbc extension is supported, > >> > as defined > >> > in version 1.0 of the Bit-Manipulation ISA extensions. > >> > > >> > * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, > >> > as defined > >> > in version 1.0 of the Bit-Manipulation ISA extensions. > >> > > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKB`: The Zbkb extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKC`: The Zbkc extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKX`: The Zbkx extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKND`: The Zknd extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNE`: The Zkne extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNH`: The Zknh extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKR`: The Zkr extension is supported, > >> > as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSED`: The Zksed extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSH`: The Zksh extension is > >> > supported, as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKT`: The Zkt extension is supported, > >> > as defined > >> > + in version 1.0 of the Scalar Cryptography ISA extensions. > >> > + > >> > * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains > >> > performance > >> > information about the selected set of processors. > >> > > >> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h > >> > b/arch/riscv/include/uapi/asm/hwprobe.h > >> > index 006bfb48343d..8357052061b3 100644 > >> > --- a/arch/riscv/include/uapi/asm/hwprobe.h > >> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h > >> > @@ -29,6 +29,17 @@ struct riscv_hwprobe { > >> > #define RISCV_HWPROBE_EXT_ZBA (1 << 3) > >> > #define RISCV_HWPROBE_EXT_ZBB (1 << 4) > >> > #define RISCV_HWPROBE_EXT_ZBS (1 << 5) > >> > +#define RISCV_HWPROBE_EXT_ZBC (1 << 6) > >> > +#define RISCV_HWPROBE_EXT_ZBKB (1 << 7) > >> > +#define RISCV_HWPROBE_EXT_ZBKC (1 << 8) > >> > +#define RISCV_HWPROBE_EXT_ZBKX (1 << 9) > >> > +#define RISCV_HWPROBE_EXT_ZKND (1 << 10) > >> > +#define RISCV_HWPROBE_EXT_ZKNE (1 << 11) > >> > +#define RISCV_HWPROBE_EXT_ZKNH (1 << 12) > >> > +#define RISCV_HWPROBE_EXT_ZKR (1 << 13) > >> > +#define RISCV_HWPROBE_EXT_ZKSED (1 << 14) > >> > +#define RISCV_HWPROBE_EXT_ZKSH (1 << 15) > >> > +#define RISCV_HWPROBE_EXT_ZKT (1 << 16) > >> > #define RISCV_HWPROBE_KEY_CPUPERF_0 5 > >> > #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0) > >> > #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0) > >> > diff --git a/arch/riscv/kernel/sys_riscv.c > >> > b/arch/riscv/kernel/sys_riscv.c > >> > index 26ef5526bfb4..df15926196b6 100644 > >> > --- a/arch/riscv/kernel/sys_riscv.c > >> > +++ b/arch/riscv/kernel/sys_riscv.c > >> > @@ -145,20 +145,28 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe > >> > *pair, > >> > for_each_cpu(cpu, cpus) { > >> > struct riscv_isainfo *isainfo = &hart_isa[cpu]; > >> > > >> > - if (riscv_isa_extension_available(isainfo->isa, ZBA)) > >> > - pair->value |= RISCV_HWPROBE_EXT_ZBA; > >> > - else > >> > - missing |= RISCV_HWPROBE_EXT_ZBA; > >> > - > >> > - if (riscv_isa_extension_available(isainfo->isa, ZBB)) > >> > - pair->value |= RISCV_HWPROBE_EXT_ZBB; > >> > - else > >> > - missing |= RISCV_HWPROBE_EXT_ZBB; > >> > - > >> > - if (riscv_isa_extension_available(isainfo->isa, ZBS)) > >> > - pair->value |= RISCV_HWPROBE_EXT_ZBS; > >> > - else > >> > - missing |= RISCV_HWPROBE_EXT_ZBS; > >> > +#define SET_HWPROBE_EXT_PAIR(ext) \ > >> > + do { \ > >> > + if (riscv_isa_extension_available(isainfo->isa, ext)) \ > >> > + pair->value |= RISCV_HWPROBE_EXT_## ext; \ > >> > + else \ > >> > + missing |= RISCV_HWPROBE_EXT_## ext; \ > >> > + } while (false) \ > >> > + > >> > + SET_HWPROBE_EXT_PAIR(ZBA); > >> > + SET_HWPROBE_EXT_PAIR(ZBB); > >> > + SET_HWPROBE_EXT_PAIR(ZBC); > >> > + SET_HWPROBE_EXT_PAIR(ZBS); > >> > + SET_HWPROBE_EXT_PAIR(ZBKB); > >> > + SET_HWPROBE_EXT_PAIR(ZBKC); > >> > + SET_HWPROBE_EXT_PAIR(ZBKX); > >> > + SET_HWPROBE_EXT_PAIR(ZKND); > >> > + SET_HWPROBE_EXT_PAIR(ZKNE); > >> > + SET_HWPROBE_EXT_PAIR(ZKNH); > >> > + SET_HWPROBE_EXT_PAIR(ZKR); > >> > >> Does the presence of a HWPROBE_EXT bit imply that userspace software can > >> actually directly use the described feature? If so, we should probably > >> not set ZKR unless mseccfg.USEED=1. > > > > mseccfg is MRW, so only accessible from M-mode only afaiu. So I don't > > think we would be able to check that from Linux in S-mode. > > Check directly, no, but your patch already makes the assumption that > mseccfg.SSEED=1 if zkr is present in the device tree. Which is fine as long > as that contract is documented somewhere (presumably, the device tree > binding; some of the language in the RVA22U64 profile spec implies USEED=0, > but linux does not require profiles and they don't exist for rv32). > > If we want U-mode behavior to be discoverable and/or predictable, we have > three good options: Thanks for the suggestions. > Simplest: Document that we expect USEED=0 or USEED=1. Set zkr appropriately > in hwprobe. > > Most flexible: Work with the SBI people to add a SBI_EXT_FWFEATURE for USEED, > as well as defining the value on kernel entry. Expose this via hwprobe and > a new prctl. I'd like to go down that route, but this depends on [1] to get accepted/merged first. Would it make sense to go with only documenting the USEED expectation for now and then move to the more flexible FWFEATURE SBI approach? Cheers, Samuel. [1] https://lists.riscv.org/g/tech-prs/message/540 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions 2023-07-10 7:59 ` Samuel Ortiz @ 2023-07-12 5:54 ` Stefan O'Rear 0 siblings, 0 replies; 27+ messages in thread From: Stefan O'Rear @ 2023-07-12 5:54 UTC (permalink / raw) To: Samuel Ortiz Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, guoren, Atish Patra, Björn Töpel, Evan Green On Mon, Jul 10, 2023, at 3:59 AM, Samuel Ortiz wrote: > On Wed, Jun 28, 2023 at 09:25:02AM -0400, Stefan O'Rear wrote: >> On Wed, Jun 28, 2023, at 6:04 AM, Samuel Ortiz wrote: >> > On Tue, Jun 27, 2023 at 08:34:20PM -0400, Stefan O'Rear wrote: >> >> On Tue, Jun 27, 2023, at 10:37 AM, Samuel Ortiz wrote: >> >> > Zbc was missing from a previous Bit-Manipulation extension hwprobe >> >> > patch. >> >> > >> >> > Add all scalar crypto extensions bits, and define a macro for setting >> >> > the hwprobe key/pair in a more readable way. >> >> > >> >> > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> >> >> > --- >> >> > Documentation/riscv/hwprobe.rst | 33 ++++++++++++++++++++++++ >> >> > arch/riscv/include/uapi/asm/hwprobe.h | 11 ++++++++ >> >> > arch/riscv/kernel/sys_riscv.c | 36 ++++++++++++++++----------- >> >> > 3 files changed, 66 insertions(+), 14 deletions(-) >> >> > >> >> > diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst >> >> > index 19165ebd82ba..3177550106e0 100644 >> >> > --- a/Documentation/riscv/hwprobe.rst >> >> > +++ b/Documentation/riscv/hwprobe.rst >> >> > @@ -72,11 +72,44 @@ The following keys are defined: >> >> > extensions. >> >> > >> >> > * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, >> >> > as defined >> >> > + in version 1.0 of the Bit-Manipulation ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBC`: The Zbc extension is supported, >> >> > as defined >> >> > in version 1.0 of the Bit-Manipulation ISA extensions. >> >> > >> >> > * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, >> >> > as defined >> >> > in version 1.0 of the Bit-Manipulation ISA extensions. >> >> > >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKB`: The Zbkb extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKC`: The Zbkc extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZBKX`: The Zbkx extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKND`: The Zknd extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNE`: The Zkne extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKNH`: The Zknh extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKR`: The Zkr extension is supported, >> >> > as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSED`: The Zksed extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKSH`: The Zksh extension is >> >> > supported, as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > + * :c:macro:`RISCV_HWPROBE_EXT_ZKT`: The Zkt extension is supported, >> >> > as defined >> >> > + in version 1.0 of the Scalar Cryptography ISA extensions. >> >> > + >> >> > * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains >> >> > performance >> >> > information about the selected set of processors. >> >> > >> >> > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h >> >> > b/arch/riscv/include/uapi/asm/hwprobe.h >> >> > index 006bfb48343d..8357052061b3 100644 >> >> > --- a/arch/riscv/include/uapi/asm/hwprobe.h >> >> > +++ b/arch/riscv/include/uapi/asm/hwprobe.h >> >> > @@ -29,6 +29,17 @@ struct riscv_hwprobe { >> >> > #define RISCV_HWPROBE_EXT_ZBA (1 << 3) >> >> > #define RISCV_HWPROBE_EXT_ZBB (1 << 4) >> >> > #define RISCV_HWPROBE_EXT_ZBS (1 << 5) >> >> > +#define RISCV_HWPROBE_EXT_ZBC (1 << 6) >> >> > +#define RISCV_HWPROBE_EXT_ZBKB (1 << 7) >> >> > +#define RISCV_HWPROBE_EXT_ZBKC (1 << 8) >> >> > +#define RISCV_HWPROBE_EXT_ZBKX (1 << 9) >> >> > +#define RISCV_HWPROBE_EXT_ZKND (1 << 10) >> >> > +#define RISCV_HWPROBE_EXT_ZKNE (1 << 11) >> >> > +#define RISCV_HWPROBE_EXT_ZKNH (1 << 12) >> >> > +#define RISCV_HWPROBE_EXT_ZKR (1 << 13) >> >> > +#define RISCV_HWPROBE_EXT_ZKSED (1 << 14) >> >> > +#define RISCV_HWPROBE_EXT_ZKSH (1 << 15) >> >> > +#define RISCV_HWPROBE_EXT_ZKT (1 << 16) >> >> > #define RISCV_HWPROBE_KEY_CPUPERF_0 5 >> >> > #define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0) >> >> > #define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0) >> >> > diff --git a/arch/riscv/kernel/sys_riscv.c >> >> > b/arch/riscv/kernel/sys_riscv.c >> >> > index 26ef5526bfb4..df15926196b6 100644 >> >> > --- a/arch/riscv/kernel/sys_riscv.c >> >> > +++ b/arch/riscv/kernel/sys_riscv.c >> >> > @@ -145,20 +145,28 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe >> >> > *pair, >> >> > for_each_cpu(cpu, cpus) { >> >> > struct riscv_isainfo *isainfo = &hart_isa[cpu]; >> >> > >> >> > - if (riscv_isa_extension_available(isainfo->isa, ZBA)) >> >> > - pair->value |= RISCV_HWPROBE_EXT_ZBA; >> >> > - else >> >> > - missing |= RISCV_HWPROBE_EXT_ZBA; >> >> > - >> >> > - if (riscv_isa_extension_available(isainfo->isa, ZBB)) >> >> > - pair->value |= RISCV_HWPROBE_EXT_ZBB; >> >> > - else >> >> > - missing |= RISCV_HWPROBE_EXT_ZBB; >> >> > - >> >> > - if (riscv_isa_extension_available(isainfo->isa, ZBS)) >> >> > - pair->value |= RISCV_HWPROBE_EXT_ZBS; >> >> > - else >> >> > - missing |= RISCV_HWPROBE_EXT_ZBS; >> >> > +#define SET_HWPROBE_EXT_PAIR(ext) \ >> >> > + do { \ >> >> > + if (riscv_isa_extension_available(isainfo->isa, ext)) \ >> >> > + pair->value |= RISCV_HWPROBE_EXT_## ext; \ >> >> > + else \ >> >> > + missing |= RISCV_HWPROBE_EXT_## ext; \ >> >> > + } while (false) \ >> >> > + >> >> > + SET_HWPROBE_EXT_PAIR(ZBA); >> >> > + SET_HWPROBE_EXT_PAIR(ZBB); >> >> > + SET_HWPROBE_EXT_PAIR(ZBC); >> >> > + SET_HWPROBE_EXT_PAIR(ZBS); >> >> > + SET_HWPROBE_EXT_PAIR(ZBKB); >> >> > + SET_HWPROBE_EXT_PAIR(ZBKC); >> >> > + SET_HWPROBE_EXT_PAIR(ZBKX); >> >> > + SET_HWPROBE_EXT_PAIR(ZKND); >> >> > + SET_HWPROBE_EXT_PAIR(ZKNE); >> >> > + SET_HWPROBE_EXT_PAIR(ZKNH); >> >> > + SET_HWPROBE_EXT_PAIR(ZKR); >> >> >> >> Does the presence of a HWPROBE_EXT bit imply that userspace software can >> >> actually directly use the described feature? If so, we should probably >> >> not set ZKR unless mseccfg.USEED=1. >> > >> > mseccfg is MRW, so only accessible from M-mode only afaiu. So I don't >> > think we would be able to check that from Linux in S-mode. >> >> Check directly, no, but your patch already makes the assumption that >> mseccfg.SSEED=1 if zkr is present in the device tree. Which is fine as long >> as that contract is documented somewhere (presumably, the device tree >> binding; some of the language in the RVA22U64 profile spec implies USEED=0, >> but linux does not require profiles and they don't exist for rv32). >> >> If we want U-mode behavior to be discoverable and/or predictable, we have >> three good options: > > Thanks for the suggestions. > >> Simplest: Document that we expect USEED=0 or USEED=1. Set zkr appropriately >> in hwprobe. >> >> Most flexible: Work with the SBI people to add a SBI_EXT_FWFEATURE for USEED, >> as well as defining the value on kernel entry. Expose this via hwprobe and >> a new prctl. > > I'd like to go down that route, but this depends on [1] to get > accepted/merged first. > > Would it make sense to go with only documenting the USEED expectation > for now and then move to the more flexible FWFEATURE SBI approach? Yes. I would start with an assumption that SSEED=1 (so that we can use it at all), USEED=0 (because many systems will want to prevent unprivileged access to raw hardware randomness, so we don't want the uABI to guarantee accessibility of seed until a mechanism has been defined to communicate USEED to userspace), and there is no nonstandard extension on the FWFT extension ID or nonstandard use of reserved feature space (so we can probe for the USEED feature to become available; this can be tightened once a specific feature ID is allocated for USEED). I assumed earlier in the thread that we would communicate USEED to userspace by conditionally setting the RISCV_HWPROBE_EXT_ZKR flag. This was an error on my part as I assumed hwprobe could return different values per process, but it uses data from the vvar area which only exists once per time namespace. A new mechanism will need to be developed. -s > Cheers, > Samuel. > > [1] https://lists.riscv.org/g/tech-prs/message/540 > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available 2023-06-27 14:37 [PATCH 0/3] RISC-V: archrandom support Samuel Ortiz 2023-06-27 14:37 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Samuel Ortiz 2023-06-27 14:37 ` [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions Samuel Ortiz @ 2023-06-27 14:37 ` Samuel Ortiz 2023-06-27 19:09 ` Conor Dooley 2023-06-28 1:00 ` Stefan O'Rear 2 siblings, 2 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-27 14:37 UTC (permalink / raw) To: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: Samuel Ortiz, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green The Zkr extension is ratified and provides 16 bits of entropy seed when reading the SEED CSR. We can implement arch_get_random_seed_longs() by doing multiple csrrw to that CSR and filling an unsigned long with valid entropy bits. Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> --- arch/riscv/include/asm/archrandom.h | 66 +++++++++++++++++++++++++++++ arch/riscv/include/asm/csr.h | 9 ++++ 2 files changed, 75 insertions(+) create mode 100644 arch/riscv/include/asm/archrandom.h diff --git a/arch/riscv/include/asm/archrandom.h b/arch/riscv/include/asm/archrandom.h new file mode 100644 index 000000000000..3d01aab2800a --- /dev/null +++ b/arch/riscv/include/asm/archrandom.h @@ -0,0 +1,66 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Kernel interface for the RISCV arch_random_* functions + * + * Copyright (c) 2022 by Rivos Inc. + * + */ + +#ifndef ASM_RISCV_ARCHRANDOM_H +#define ASM_RISCV_ARCHRANDOM_H + +#include <asm/csr.h> + +#define PR_PREFIX "Zkr Extension: " +#define SEED_RETRY_LOOPS 10 + +static inline bool __must_check csr_seed_long(unsigned long *v) +{ + unsigned int retry = SEED_RETRY_LOOPS; + unsigned int needed_seeds = sizeof(unsigned long) / 2, valid_seeds = 0; + u16 *entropy = (u16 *)v; + + do { + /* + * The SEED CSR (0x015) must be accessed with a read-write + * instruction. Moreover, implementations must ignore the write + * value, its purpose is to signal polling for new seed. + */ + unsigned long csr_seed = csr_swap(CSR_SEED, 0); + + switch (csr_seed & SEED_OPST_MASK) { + case SEED_OPST_ES16: + entropy[valid_seeds++] = csr_seed & SEED_ENTROPY_MASK; + if (valid_seeds == needed_seeds) + return true; + break; + + case SEED_OPST_DEAD: + pr_err_once(PR_PREFIX "Unrecoverable error\n"); + return false; + + case SEED_OPST_BIST: + pr_info(PR_PREFIX "On going Built-in Self Test\n"); + fallthrough; + + case SEED_OPST_WAIT: + default: + continue; + } + + } while (--retry); + + return false; +} + +static inline size_t __must_check arch_get_random_longs(unsigned long *v, size_t max_longs) +{ + return 0; +} + +static inline size_t __must_check arch_get_random_seed_longs(unsigned long *v, size_t max_longs) +{ + return max_longs && riscv_isa_extension_available(NULL, ZKR) && csr_seed_long(v) ? 1 : 0; +} + +#endif /* ASM_RISCV_ARCHRANDOM_H */ diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h index b98b3b6c9da2..7d0ca9082c66 100644 --- a/arch/riscv/include/asm/csr.h +++ b/arch/riscv/include/asm/csr.h @@ -389,6 +389,15 @@ #define CSR_VTYPE 0xc21 #define CSR_VLENB 0xc22 +/* Scalar Crypto Extension - Entropy */ +#define CSR_SEED 0x015 +#define SEED_OPST_MASK _AC(0xC0000000, UL) +#define SEED_OPST_BIST _AC(0x00000000, UL) +#define SEED_OPST_WAIT _AC(0x40000000, UL) +#define SEED_OPST_ES16 _AC(0x80000000, UL) +#define SEED_OPST_DEAD _AC(0xC0000000, UL) +#define SEED_ENTROPY_MASK _AC(0xFFFF, UL) + #ifdef CONFIG_RISCV_M_MODE # define CSR_STATUS CSR_MSTATUS # define CSR_IE CSR_MIE -- 2.41.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available 2023-06-27 14:37 ` [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available Samuel Ortiz @ 2023-06-27 19:09 ` Conor Dooley 2023-06-28 12:28 ` Samuel Ortiz 2023-06-28 1:00 ` Stefan O'Rear 1 sibling, 1 reply; 27+ messages in thread From: Conor Dooley @ 2023-06-27 19:09 UTC (permalink / raw) To: Samuel Ortiz Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green [-- Attachment #1: Type: text/plain, Size: 4351 bytes --] Hey Samuel, On Tue, Jun 27, 2023 at 04:37:44PM +0200, Samuel Ortiz wrote: > The Zkr extension is ratified and provides 16 bits of entropy seed when > reading the SEED CSR. > > We can implement arch_get_random_seed_longs() by doing multiple csrrw to > that CSR and filling an unsigned long with valid entropy bits. > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > --- > arch/riscv/include/asm/archrandom.h | 66 +++++++++++++++++++++++++++++ > arch/riscv/include/asm/csr.h | 9 ++++ > 2 files changed, 75 insertions(+) > create mode 100644 arch/riscv/include/asm/archrandom.h > > diff --git a/arch/riscv/include/asm/archrandom.h b/arch/riscv/include/asm/archrandom.h > new file mode 100644 > index 000000000000..3d01aab2800a > --- /dev/null > +++ b/arch/riscv/include/asm/archrandom.h > @@ -0,0 +1,66 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Kernel interface for the RISCV arch_random_* functions > + * > + * Copyright (c) 2022 by Rivos Inc. > + * > + */ > + > +#ifndef ASM_RISCV_ARCHRANDOM_H > +#define ASM_RISCV_ARCHRANDOM_H > + > +#include <asm/csr.h> > + > +#define PR_PREFIX "Zkr Extension: " Does pr_fmt() not work for you? Also, "Zkr Extension" doesn't really seem super helpful to a punter if they saw it in a log. Why not s/Zkr Extension/archrandom/, or similar? > +#define SEED_RETRY_LOOPS 10 > + > +static inline bool __must_check csr_seed_long(unsigned long *v) > +{ > + unsigned int retry = SEED_RETRY_LOOPS; > + unsigned int needed_seeds = sizeof(unsigned long) / 2, valid_seeds = 0; > + u16 *entropy = (u16 *)v; > + > + do { > + /* > + * The SEED CSR (0x015) must be accessed with a read-write > + * instruction. Moreover, implementations must ignore the write > + * value, its purpose is to signal polling for new seed. > + */ What relevance does the second half of this comment have to the kernel? > + unsigned long csr_seed = csr_swap(CSR_SEED, 0); > + > + switch (csr_seed & SEED_OPST_MASK) { > + case SEED_OPST_ES16: > + entropy[valid_seeds++] = csr_seed & SEED_ENTROPY_MASK; > + if (valid_seeds == needed_seeds) > + return true; > + break; > + > + case SEED_OPST_DEAD: > + pr_err_once(PR_PREFIX "Unrecoverable error\n"); > + return false; > + > + case SEED_OPST_BIST: > + pr_info(PR_PREFIX "On going Built-in Self Test\n"); tiny nit, "On-going"? My OCD is bother by the capitalisation otherwise. > + fallthrough; > + > + case SEED_OPST_WAIT: > + default: > + continue; > + } > + > + } while (--retry); > + > + return false; > +} > + > +static inline size_t __must_check arch_get_random_longs(unsigned long *v, size_t max_longs) > +{ > + return 0; > +} > + > +static inline size_t __must_check arch_get_random_seed_longs(unsigned long *v, size_t max_longs) > +{ > + return max_longs && riscv_isa_extension_available(NULL, ZKR) && csr_seed_long(v) ? 1 : 0; Could you please write this in a more readable way, even if that is going to be a lot more verbose? I know you copied it from x86, but that's not really an excuse ;) Also, is there a reason that you opted not to use the alternative-backed riscv_has_extension_[un]likely() here? The ones backed by alternatives are preferred if you are not checking on a per-cpu, or once-off basis. Cheers, Conor. > +} > + > +#endif /* ASM_RISCV_ARCHRANDOM_H */ > diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h > index b98b3b6c9da2..7d0ca9082c66 100644 > --- a/arch/riscv/include/asm/csr.h > +++ b/arch/riscv/include/asm/csr.h > @@ -389,6 +389,15 @@ > #define CSR_VTYPE 0xc21 > #define CSR_VLENB 0xc22 > > +/* Scalar Crypto Extension - Entropy */ > +#define CSR_SEED 0x015 > +#define SEED_OPST_MASK _AC(0xC0000000, UL) > +#define SEED_OPST_BIST _AC(0x00000000, UL) > +#define SEED_OPST_WAIT _AC(0x40000000, UL) > +#define SEED_OPST_ES16 _AC(0x80000000, UL) > +#define SEED_OPST_DEAD _AC(0xC0000000, UL) > +#define SEED_ENTROPY_MASK _AC(0xFFFF, UL) > + > #ifdef CONFIG_RISCV_M_MODE > # define CSR_STATUS CSR_MSTATUS > # define CSR_IE CSR_MIE > -- > 2.41.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available 2023-06-27 19:09 ` Conor Dooley @ 2023-06-28 12:28 ` Samuel Ortiz 0 siblings, 0 replies; 27+ messages in thread From: Samuel Ortiz @ 2023-06-28 12:28 UTC (permalink / raw) To: Conor Dooley Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green Hi Conor, On Tue, Jun 27, 2023 at 08:09:08PM +0100, Conor Dooley wrote: > On Tue, Jun 27, 2023 at 04:37:44PM +0200, Samuel Ortiz wrote: > > The Zkr extension is ratified and provides 16 bits of entropy seed when > > reading the SEED CSR. > > > > We can implement arch_get_random_seed_longs() by doing multiple csrrw to > > that CSR and filling an unsigned long with valid entropy bits. > > > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > > --- > > arch/riscv/include/asm/archrandom.h | 66 +++++++++++++++++++++++++++++ > > arch/riscv/include/asm/csr.h | 9 ++++ > > 2 files changed, 75 insertions(+) > > create mode 100644 arch/riscv/include/asm/archrandom.h > > > > diff --git a/arch/riscv/include/asm/archrandom.h b/arch/riscv/include/asm/archrandom.h > > new file mode 100644 > > index 000000000000..3d01aab2800a > > --- /dev/null > > +++ b/arch/riscv/include/asm/archrandom.h > > @@ -0,0 +1,66 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Kernel interface for the RISCV arch_random_* functions > > + * > > + * Copyright (c) 2022 by Rivos Inc. > > + * > > + */ > > + > > +#ifndef ASM_RISCV_ARCHRANDOM_H > > +#define ASM_RISCV_ARCHRANDOM_H > > + > > +#include <asm/csr.h> > > + > > +#define PR_PREFIX "Zkr Extension: " > > Does pr_fmt() not work for you? It would, but since this is a header that e.g. gets included in random.h, I would have to ifndef it first. My v2 is less verbose and gets rid of this prefix anyways. > Also, "Zkr Extension" doesn't really seem super helpful to a punter if > they saw it in a log. Why not s/Zkr Extension/archrandom/, or similar? > > > +#define SEED_RETRY_LOOPS 10 > > + > > +static inline bool __must_check csr_seed_long(unsigned long *v) > > +{ > > + unsigned int retry = SEED_RETRY_LOOPS; > > + unsigned int needed_seeds = sizeof(unsigned long) / 2, valid_seeds = 0; > > + u16 *entropy = (u16 *)v; > > + > > + do { > > + /* > > + * The SEED CSR (0x015) must be accessed with a read-write > > + * instruction. Moreover, implementations must ignore the write > > + * value, its purpose is to signal polling for new seed. > > + */ > > What relevance does the second half of this comment have to the kernel? Not much, I will remove it with v2. > > + unsigned long csr_seed = csr_swap(CSR_SEED, 0); > > + > > + switch (csr_seed & SEED_OPST_MASK) { > > + case SEED_OPST_ES16: > > + entropy[valid_seeds++] = csr_seed & SEED_ENTROPY_MASK; > > + if (valid_seeds == needed_seeds) > > + return true; > > + break; > > + > > + case SEED_OPST_DEAD: > > + pr_err_once(PR_PREFIX "Unrecoverable error\n"); > > + return false; > > + > > + case SEED_OPST_BIST: > > + pr_info(PR_PREFIX "On going Built-in Self Test\n"); > > tiny nit, "On-going"? My OCD is bother by the capitalisation otherwise. I removed that one with v2, as it may be a little too chatty. > > + fallthrough; > > + > > + case SEED_OPST_WAIT: > > + default: > > + continue; > > + } > > + > > + } while (--retry); > > + > > + return false; > > +} > > + > > +static inline size_t __must_check arch_get_random_longs(unsigned long *v, size_t max_longs) > > +{ > > + return 0; > > +} > > + > > +static inline size_t __must_check arch_get_random_seed_longs(unsigned long *v, size_t max_longs) > > +{ > > + return max_longs && riscv_isa_extension_available(NULL, ZKR) && csr_seed_long(v) ? 1 : 0; > > Could you please write this in a more readable way, even if that is > going to be a lot more verbose? I know you copied it from x86, but > that's not really an excuse ;) Agreed :) Fixed as well with v2. > Also, is there a reason that you opted not to use the alternative-backed > riscv_has_extension_[un]likely() here? I did not know about them, I switched to it with v2 (Made it a likely case). Cheers, Samuel. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available 2023-06-27 14:37 ` [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available Samuel Ortiz 2023-06-27 19:09 ` Conor Dooley @ 2023-06-28 1:00 ` Stefan O'Rear 1 sibling, 0 replies; 27+ messages in thread From: Stefan O'Rear @ 2023-06-28 1:00 UTC (permalink / raw) To: Samuel Ortiz, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: linux, Conor Dooley, Andrew Jones, Heiko Stuebner, Anup Patel, linux-kernel, Hongren (Zenithal) Zheng, Guo Ren, Atish Patra, Björn Töpel, Evan Green On Tue, Jun 27, 2023, at 10:37 AM, Samuel Ortiz wrote: > The Zkr extension is ratified and provides 16 bits of entropy seed when > reading the SEED CSR. > > We can implement arch_get_random_seed_longs() by doing multiple csrrw to > that CSR and filling an unsigned long with valid entropy bits. > > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com> > --- > arch/riscv/include/asm/archrandom.h | 66 +++++++++++++++++++++++++++++ > arch/riscv/include/asm/csr.h | 9 ++++ > 2 files changed, 75 insertions(+) > create mode 100644 arch/riscv/include/asm/archrandom.h > > diff --git a/arch/riscv/include/asm/archrandom.h > b/arch/riscv/include/asm/archrandom.h > new file mode 100644 > index 000000000000..3d01aab2800a > --- /dev/null > +++ b/arch/riscv/include/asm/archrandom.h > @@ -0,0 +1,66 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Kernel interface for the RISCV arch_random_* functions > + * > + * Copyright (c) 2022 by Rivos Inc. > + * > + */ > + > +#ifndef ASM_RISCV_ARCHRANDOM_H > +#define ASM_RISCV_ARCHRANDOM_H > + > +#include <asm/csr.h> > + > +#define PR_PREFIX "Zkr Extension: " > +#define SEED_RETRY_LOOPS 10 > + > +static inline bool __must_check csr_seed_long(unsigned long *v) > +{ > + unsigned int retry = SEED_RETRY_LOOPS; > + unsigned int needed_seeds = sizeof(unsigned long) / 2, valid_seeds = > 0; > + u16 *entropy = (u16 *)v; > + > + do { > + /* > + * The SEED CSR (0x015) must be accessed with a read-write > + * instruction. Moreover, implementations must ignore the write > + * value, its purpose is to signal polling for new seed. > + */ > + unsigned long csr_seed = csr_swap(CSR_SEED, 0); > + > + switch (csr_seed & SEED_OPST_MASK) { > + case SEED_OPST_ES16: > + entropy[valid_seeds++] = csr_seed & SEED_ENTROPY_MASK; > + if (valid_seeds == needed_seeds) > + return true; > + break; > + > + case SEED_OPST_DEAD: > + pr_err_once(PR_PREFIX "Unrecoverable error\n"); > + return false; > + > + case SEED_OPST_BIST: > + pr_info(PR_PREFIX "On going Built-in Self Test\n"); > + fallthrough; > + > + case SEED_OPST_WAIT: > + default: > + continue; > + } > + > + } while (--retry); > + > + return false; > +} The Entropy Source specification is annoyingly vague about expected retry counts, only saying that "Without a polling-style mechanism, the entropy source could hang for thousands of cycles under some circumstances." Likewise no constraint is placed on the maximum runtime of a BIST or the maximum number of times SEED_OPST_BIST is repeatedly returned (only that it be returned at least once if the BIST starts and finishes between seed reads). With that, the limit of 10 reads seems suspiciously small. Is there a specific justification or is it known to work on some hardware? -s > + > +static inline size_t __must_check arch_get_random_longs(unsigned long > *v, size_t max_longs) > +{ > + return 0; > +} > + > +static inline size_t __must_check arch_get_random_seed_longs(unsigned > long *v, size_t max_longs) > +{ > + return max_longs && riscv_isa_extension_available(NULL, ZKR) && > csr_seed_long(v) ? 1 : 0; > +} > + > +#endif /* ASM_RISCV_ARCHRANDOM_H */ > diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h > index b98b3b6c9da2..7d0ca9082c66 100644 > --- a/arch/riscv/include/asm/csr.h > +++ b/arch/riscv/include/asm/csr.h > @@ -389,6 +389,15 @@ > #define CSR_VTYPE 0xc21 > #define CSR_VLENB 0xc22 > > +/* Scalar Crypto Extension - Entropy */ > +#define CSR_SEED 0x015 > +#define SEED_OPST_MASK _AC(0xC0000000, UL) > +#define SEED_OPST_BIST _AC(0x00000000, UL) > +#define SEED_OPST_WAIT _AC(0x40000000, UL) > +#define SEED_OPST_ES16 _AC(0x80000000, UL) > +#define SEED_OPST_DEAD _AC(0xC0000000, UL) > +#define SEED_ENTROPY_MASK _AC(0xFFFF, UL) > + > #ifdef CONFIG_RISCV_M_MODE > # define CSR_STATUS CSR_MSTATUS > # define CSR_IE CSR_MIE > -- > 2.41.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2023-07-12 5:55 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-27 14:37 [PATCH 0/3] RISC-V: archrandom support Samuel Ortiz
2023-06-27 14:37 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Samuel Ortiz
2023-06-27 18:14 ` Evan Green
2023-06-27 18:44 ` Hongren (Zenithal) Zheng
2023-06-27 18:48 ` Conor Dooley
2023-06-27 19:03 ` Hongren (Zenithal) Zheng
2023-06-27 19:18 ` Conor Dooley
2023-06-28 9:59 ` Samuel Ortiz
2023-06-28 10:01 ` Samuel Ortiz
2023-06-28 11:10 ` Conor Dooley
2023-06-28 12:30 ` Samuel Ortiz
2023-06-28 16:49 ` Conor Dooley
2023-06-28 17:18 ` Evan Green
2023-06-28 17:24 ` Conor Dooley
2023-07-03 17:39 ` Conor Dooley
[not found] ` <97a7d701-3b48-252e-6d78-ef3d0e7f8f03@web.de>
2023-06-28 12:29 ` Samuel Ortiz
2023-06-27 14:37 ` [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions Samuel Ortiz
2023-06-27 18:13 ` Evan Green
2023-06-28 0:34 ` Stefan O'Rear
2023-06-28 10:04 ` Samuel Ortiz
2023-06-28 13:25 ` Stefan O'Rear
2023-07-10 7:59 ` Samuel Ortiz
2023-07-12 5:54 ` Stefan O'Rear
2023-06-27 14:37 ` [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available Samuel Ortiz
2023-06-27 19:09 ` Conor Dooley
2023-06-28 12:28 ` Samuel Ortiz
2023-06-28 1:00 ` Stefan O'Rear
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox