* [PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP @ 2022-06-12 18:44 Hongren (Zenithal) Zheng 2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Hongren (Zenithal) Zheng @ 2022-06-12 18:44 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Albert Ou Cc: Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner, Conor.Dooley This patchset proposes a currently viable and forward compatible way to expose the bitmanip/scalar crypto capability of the platform to the userspace. Currently viable refers to the property that hardware platforms can easily modify the riscv,isa field in DT to tell the kernel it has the capability. Note that QEMU has already done so in its device tree. Forward compatible refers to the property that userspace can still detect the capability of the environment by using HWCAP regardless of how the mechanism changes below kernel in the future. I do know that it has not been settled how to discover a capability, but I think kernel has to offer some API after all, and HWCAP is the preferred way among other mechanisms for now. A note here is that the draft riscv-platform spec considers DT as mandatory discovery mechanism for embedded platform For other discovery mechanism like ACPI/SMBIOS, similar code path can be added but the HWCAP interface could remain unchanged More discussion on userspace discovering can be found on my PR to openssl https://github.com/openssl/openssl/pull/18197 --- v2: * Fixed checkpatch problem found by Heiko Stuebner * rebased on riscv/for-next as that branch has merged the support of Svpbmt extension * Changed the order of logical ids in riscv_isa_ext_id to the order specified in riscv-isa-manual * added note on riscv-platform-spec v3: * rebased on master as riscv/for-next has been merged * fix commit message as suggested by Conor Dooley Hongren (Zenithal) Zheng (3): RISC-V: add Bitmanip/Scalar Crypto parsing from DT RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT arch/riscv/include/asm/elf.h | 2 + arch/riscv/include/asm/hwcap.h | 22 +++++++- arch/riscv/include/uapi/asm/hwcap.h | 22 ++++++++ arch/riscv/kernel/cpu.c | 14 +++++ arch/riscv/kernel/cpufeature.c | 81 +++++++++++++++++++++++++---- 5 files changed, 129 insertions(+), 12 deletions(-) -- 2.35.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2022-06-12 18:44 [PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Hongren (Zenithal) Zheng @ 2022-06-12 18:46 ` Hongren (Zenithal) Zheng 2022-11-24 9:19 ` Samuel Ortiz 2022-11-24 11:53 ` Conor Dooley 2022-06-12 18:46 ` [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto Hongren (Zenithal) Zheng 2022-06-12 18:47 ` [PATCH v3 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT Hongren (Zenithal) Zheng 2 siblings, 2 replies; 15+ messages in thread From: Hongren (Zenithal) Zheng @ 2022-06-12 18:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Albert Ou Cc: Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner, Conor.Dooley 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 | 20 +++++++++++++++++++- arch/riscv/kernel/cpu.c | 14 ++++++++++++++ arch/riscv/kernel/cpufeature.c | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 66 insertions(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index 4e2486881840..02c454a12683 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -49,9 +49,27 @@ extern unsigned long elf_hwcap; * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter * extensions while all the multi-letter extensions should define the next * available logical extension id. + * + * The order of them should be maintained according to the riscv-isa-manual. + * As this is an internal API, changing the id of one extension does + * not affect compatibility. */ enum riscv_isa_ext_id { - RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE, + RISCV_ISA_EXT_ZBA = RISCV_ISA_EXT_BASE, + RISCV_ISA_EXT_ZBB, + RISCV_ISA_EXT_ZBC, + RISCV_ISA_EXT_ZBKB, + RISCV_ISA_EXT_ZBKC, + RISCV_ISA_EXT_ZBKX, + RISCV_ISA_EXT_ZBS, + RISCV_ISA_EXT_ZKND, + RISCV_ISA_EXT_ZKNE, + RISCV_ISA_EXT_ZKNH, + RISCV_ISA_EXT_ZKR, + RISCV_ISA_EXT_ZKSED, + RISCV_ISA_EXT_ZKSH, + RISCV_ISA_EXT_ZKT, + RISCV_ISA_EXT_SSCOFPMF, RISCV_ISA_EXT_SVPBMT, RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX, }; diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index fba9e9f46a8c..d9ff9bff3d45 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -87,6 +87,20 @@ int riscv_of_parent_hartid(struct device_node *node) * extensions by an underscore. */ static struct riscv_isa_ext_data isa_ext_arr[] = { + __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(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index a6f62a6d1edd..0c2638365ec2 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -199,6 +199,39 @@ void __init riscv_fill_hwcap(void) } else { SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); 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("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("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("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.35.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng @ 2022-11-24 9:19 ` Samuel Ortiz 2022-11-24 11:53 ` Conor Dooley 1 sibling, 0 replies; 15+ messages in thread From: Samuel Ortiz @ 2022-11-24 9:19 UTC (permalink / raw) To: Hongren (Zenithal) Zheng Cc: Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner, Conor.Dooley Hi, On Mon, Jun 13, 2022 at 02:46:01AM +0800, Hongren (Zenithal) Zheng wrote: > 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> FWIW, after some rebasing: Tested-by: Samuel Ortiz <sameo@rivosinc.com> Cheers, Samuel. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT 2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng 2022-11-24 9:19 ` Samuel Ortiz @ 2022-11-24 11:53 ` Conor Dooley 1 sibling, 0 replies; 15+ messages in thread From: Conor Dooley @ 2022-11-24 11:53 UTC (permalink / raw) To: Hongren (Zenithal) Zheng Cc: Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner Hey Hongren, On Mon, Jun 13, 2022 at 02:46:01AM +0800, Hongren (Zenithal) Zheng wrote: > This patch parses Zb/Zk related string from DT and > output them in cpuinfo Could you please wrap changelogs at 72 character rather than 50? > > 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. Where is the "DT binding spec" for this? At the time, IIRC, putting any multiletter extensions in a DT was a violation of the dt-binding, so I am interested in seeing what spec had covered 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 | 20 +++++++++++++++++++- > arch/riscv/kernel/cpu.c | 14 ++++++++++++++ > arch/riscv/kernel/cpufeature.c | 33 +++++++++++++++++++++++++++++++++ > 3 files changed, 66 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > index 4e2486881840..02c454a12683 100644 > --- a/arch/riscv/include/asm/hwcap.h > +++ b/arch/riscv/include/asm/hwcap.h > @@ -49,9 +49,27 @@ extern unsigned long elf_hwcap; > * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter > * extensions while all the multi-letter extensions should define the next > * available logical extension id. > + * > + * The order of them should be maintained according to the riscv-isa-manual. > + * As this is an internal API, changing the id of one extension does > + * not affect compatibility. Hmm, not too sure about this. See 61a41d16ad20 ("RISC-V: Print SSTC in canonical order"), where Palmer re-sorted another one of these internal APIs (isa_ext_arr) in a different order to what it would appear you're proposing here. I am really really bad when it comes to specs, manuals etc - is there a link to the specific part of the riscv-isa-manual that we can use here for reference? Otherwise I'd much rather stick with what I **thought** was the "canonical order", _Sfoo_Zfoo_Xfoo. Or are these slightly different - and fit in the "Additional Standard Extension Names" category rather than "Machine-level Instruction-Set Extensions"? The only ones I see pointed out in the current table [0] are Ztso, Zicsr, Zifencei & Zam which is what I (maybe wrongly!!) assumed to be the exceptions to the S before Z rule. I tried to have a look in the "bitmanip-1.0.0" pdf at [2], but I don't see it use the word "Standard" anywhere. As I already said, this stuff confuses me no end so some clarification would be really helpful :) The same applies to the crypto stuff. In other news, since Palmer did do a re-order, and its been several months - you'll need to rebase & re-submit anyway. Thanks, Conor. 0 - https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L132 1 - https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L182 2 - https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0 > */ > enum riscv_isa_ext_id { > - RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE, > + RISCV_ISA_EXT_ZBA = RISCV_ISA_EXT_BASE, > + RISCV_ISA_EXT_ZBB, > + RISCV_ISA_EXT_ZBC, > + RISCV_ISA_EXT_ZBKB, > + RISCV_ISA_EXT_ZBKC, > + RISCV_ISA_EXT_ZBKX, > + RISCV_ISA_EXT_ZBS, > + RISCV_ISA_EXT_ZKND, > + RISCV_ISA_EXT_ZKNE, > + RISCV_ISA_EXT_ZKNH, > + RISCV_ISA_EXT_ZKR, > + RISCV_ISA_EXT_ZKSED, > + RISCV_ISA_EXT_ZKSH, > + RISCV_ISA_EXT_ZKT, > + RISCV_ISA_EXT_SSCOFPMF, > RISCV_ISA_EXT_SVPBMT, > RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX, > }; > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > index fba9e9f46a8c..d9ff9bff3d45 100644 > --- a/arch/riscv/kernel/cpu.c > +++ b/arch/riscv/kernel/cpu.c > @@ -87,6 +87,20 @@ int riscv_of_parent_hartid(struct device_node *node) > * extensions by an underscore. > */ > static struct riscv_isa_ext_data isa_ext_arr[] = { > + __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(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), > __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index a6f62a6d1edd..0c2638365ec2 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -199,6 +199,39 @@ void __init riscv_fill_hwcap(void) > } else { > SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); > 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("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("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("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.35.1 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-06-12 18:44 [PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Hongren (Zenithal) Zheng 2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng @ 2022-06-12 18:46 ` Hongren (Zenithal) Zheng 2022-11-24 9:30 ` Samuel Ortiz 2022-06-12 18:47 ` [PATCH v3 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT Hongren (Zenithal) Zheng 2 siblings, 1 reply; 15+ messages in thread From: Hongren (Zenithal) Zheng @ 2022-06-12 18:46 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Albert Ou Cc: Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner, Conor.Dooley userspace currently lacks a way to detect whether the platform has Bitmanip/Scalar Crypto capability, this patch adds an interface such that the userspace can detect it. RISC-V currently still has no mature mechanism, but no matter how things in the spec changes, (no matter how "M" mode things change), the kernel still needs to offer some API to the userspace. More discussion can be found at https://github.com/openssl/openssl/pull/18197 In short, userspace currently has to use env var to detect them. This interface does not make any assumptions about the underlying hardware Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> --- arch/riscv/include/uapi/asm/hwcap.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h index 46dc3f5ee99f..bfed3e5c338c 100644 --- a/arch/riscv/include/uapi/asm/hwcap.h +++ b/arch/riscv/include/uapi/asm/hwcap.h @@ -22,4 +22,26 @@ #define COMPAT_HWCAP_ISA_D (1 << ('D' - 'A')) #define COMPAT_HWCAP_ISA_C (1 << ('C' - 'A')) +/* + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2 + * + * As only 32 bits of elf_hwcap (in kernel) could be used + * and RISC-V has reserved 26 bits of it, other caps like + * bitmanip and crypto can not be placed in AT_HWCAP + */ +#define COMPAT_HWCAP2_ISA_ZBA (1 << 0) +#define COMPAT_HWCAP2_ISA_ZBB (1 << 1) +#define COMPAT_HWCAP2_ISA_ZBC (1 << 2) +#define COMPAT_HWCAP2_ISA_ZBS (1 << 3) +#define COMPAT_HWCAP2_ISA_ZBKB (1 << 4) +#define COMPAT_HWCAP2_ISA_ZBKC (1 << 5) +#define COMPAT_HWCAP2_ISA_ZBKX (1 << 6) +#define COMPAT_HWCAP2_ISA_ZKND (1 << 7) +#define COMPAT_HWCAP2_ISA_ZKNE (1 << 8) +#define COMPAT_HWCAP2_ISA_ZKNH (1 << 9) +#define COMPAT_HWCAP2_ISA_ZKSED (1 << 10) +#define COMPAT_HWCAP2_ISA_ZKSH (1 << 11) +#define COMPAT_HWCAP2_ISA_ZKR (1 << 12) +#define COMPAT_HWCAP2_ISA_ZKT (1 << 13) + #endif /* _UAPI_ASM_RISCV_HWCAP_H */ -- 2.35.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-06-12 18:46 ` [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto Hongren (Zenithal) Zheng @ 2022-11-24 9:30 ` Samuel Ortiz 2022-11-24 9:58 ` Conor Dooley 0 siblings, 1 reply; 15+ messages in thread From: Samuel Ortiz @ 2022-11-24 9:30 UTC (permalink / raw) To: Hongren (Zenithal) Zheng Cc: Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner, Conor.Dooley On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote: > diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h > index 46dc3f5ee99f..bfed3e5c338c 100644 > --- a/arch/riscv/include/uapi/asm/hwcap.h > +++ b/arch/riscv/include/uapi/asm/hwcap.h > @@ -22,4 +22,26 @@ > #define COMPAT_HWCAP_ISA_D (1 << ('D' - 'A')) > #define COMPAT_HWCAP_ISA_C (1 << ('C' - 'A')) > > +/* > + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2 > + * > + * As only 32 bits of elf_hwcap (in kernel) could be used > + * and RISC-V has reserved 26 bits of it, other caps like > + * bitmanip and crypto can not be placed in AT_HWCAP > + */ Have we agreed that multi-letter ISA extensions would use hwcap to be exposed to userspace? With so many potential extensions, we could quickly run out of space on AT_HWCAP2 as well. Cheers, Samuel. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 9:30 ` Samuel Ortiz @ 2022-11-24 9:58 ` Conor Dooley 2022-11-24 10:47 ` Samuel Ortiz 0 siblings, 1 reply; 15+ messages in thread From: Conor Dooley @ 2022-11-24 9:58 UTC (permalink / raw) To: Samuel Ortiz Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On Thu, Nov 24, 2022 at 10:30:21AM +0100, Samuel Ortiz wrote: > On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote: > > diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h > > index 46dc3f5ee99f..bfed3e5c338c 100644 > > --- a/arch/riscv/include/uapi/asm/hwcap.h > > +++ b/arch/riscv/include/uapi/asm/hwcap.h > > @@ -22,4 +22,26 @@ > > #define COMPAT_HWCAP_ISA_D (1 << ('D' - 'A')) > > #define COMPAT_HWCAP_ISA_C (1 << ('C' - 'A')) > > > > +/* > > + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2 > > + * > > + * As only 32 bits of elf_hwcap (in kernel) could be used > > + * and RISC-V has reserved 26 bits of it, other caps like > > + * bitmanip and crypto can not be placed in AT_HWCAP > > + */ > > Have we agreed that multi-letter ISA extensions would use hwcap to be > exposed to userspace? With so many potential extensions, we could > quickly run out of space on AT_HWCAP2 as well. Palmer whipped up a PoC hwprobe interface (during Plumbers I think) that Heiko is currently looking into - I think his motivation is misaligned access performance. There's a branch but I have no idea if it even compiles... I'm mostly waiting for whatever Heiko comes up with ;) https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-hwprobe-v1 This patchset seems to need a rebase anyway per your other reply, but I guess that the new proposed interface would be preferable? Thanks, Conor. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 9:58 ` Conor Dooley @ 2022-11-24 10:47 ` Samuel Ortiz 2022-11-24 11:55 ` Conor Dooley 0 siblings, 1 reply; 15+ messages in thread From: Samuel Ortiz @ 2022-11-24 10:47 UTC (permalink / raw) To: Conor Dooley Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On Thu, Nov 24, 2022 at 09:58:53AM +0000, Conor Dooley wrote: > On Thu, Nov 24, 2022 at 10:30:21AM +0100, Samuel Ortiz wrote: > > On Mon, Jun 13, 2022 at 02:46:35AM +0800, Hongren (Zenithal) Zheng wrote: > > > diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h > > > index 46dc3f5ee99f..bfed3e5c338c 100644 > > > --- a/arch/riscv/include/uapi/asm/hwcap.h > > > +++ b/arch/riscv/include/uapi/asm/hwcap.h > > > @@ -22,4 +22,26 @@ > > > #define COMPAT_HWCAP_ISA_D (1 << ('D' - 'A')) > > > #define COMPAT_HWCAP_ISA_C (1 << ('C' - 'A')) > > > > > > +/* > > > + * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2 > > > + * > > > + * As only 32 bits of elf_hwcap (in kernel) could be used > > > + * and RISC-V has reserved 26 bits of it, other caps like > > > + * bitmanip and crypto can not be placed in AT_HWCAP > > > + */ > > > > Have we agreed that multi-letter ISA extensions would use hwcap to be > > exposed to userspace? With so many potential extensions, we could > > quickly run out of space on AT_HWCAP2 as well. > > Palmer whipped up a PoC hwprobe interface (during Plumbers I think) that > Heiko is currently looking into - I think his motivation is misaligned > access performance. There's a branch but I have no idea if it even > compiles... I'm mostly waiting for whatever Heiko comes up with ;) > > https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-hwprobe-v1 > > This patchset seems to need a rebase anyway per your other reply, but I > guess that the new proposed interface would be preferable? I think so, yes. Patch #1 is definitely needed regardless of which interface we pick for exposing the ISA strings to userspace. Cheers, Samuel. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 10:47 ` Samuel Ortiz @ 2022-11-24 11:55 ` Conor Dooley 2022-11-24 17:12 ` Samuel Ortiz 0 siblings, 1 reply; 15+ messages in thread From: Conor Dooley @ 2022-11-24 11:55 UTC (permalink / raw) To: Samuel Ortiz Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote: > Patch #1 is definitely needed regardless of which interface we pick for > exposing the ISA strings to userspace. I took another look at #1, and I feel more confused about what constitutes canonical order than I did before! If you know better than I, and you probably do since you're interested in these 6 month old patches, some insight would be appreciated! Thanks, Conor. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 11:55 ` Conor Dooley @ 2022-11-24 17:12 ` Samuel Ortiz 2022-11-24 17:20 ` Conor Dooley 0 siblings, 1 reply; 15+ messages in thread From: Samuel Ortiz @ 2022-11-24 17:12 UTC (permalink / raw) To: Conor Dooley Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote: > On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote: > > > Patch #1 is definitely needed regardless of which interface we pick for > > exposing the ISA strings to userspace. > > I took another look at #1, and I feel more confused about what > constitutes canonical order than I did before! If you know better than > I, and you probably do since you're interested in these 6 month old > patches, some insight would be appreciated! Assuming we don't go with hwcap, I dont think the order of the riscv_isa_ext_id enum matters that much? iiuc we're building the cpuinfo string from the riscv_isa_ext_data array, and I think the current code is incorrect: static struct riscv_isa_ext_data isa_ext_arr[] = { __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), }; zicbom and zihintpause should come before supervisor level extensions. I'm going to send a patch for that. And the Zb/Zk ones should come after the Zi ones, and before the supervisor level ones (The I category comes before the B or the K one). So we should check that when patch #1 is rebased. Cheers, Samuel. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 17:12 ` Samuel Ortiz @ 2022-11-24 17:20 ` Conor Dooley 2022-11-24 17:34 ` Samuel Ortiz 0 siblings, 1 reply; 15+ messages in thread From: Conor Dooley @ 2022-11-24 17:20 UTC (permalink / raw) To: Samuel Ortiz Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On 24/11/2022 17:12, Samuel Ortiz wrote: > [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote: >> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote: >> >>> Patch #1 is definitely needed regardless of which interface we pick for >>> exposing the ISA strings to userspace. >> >> I took another look at #1, and I feel more confused about what >> constitutes canonical order than I did before! If you know better than >> I, and you probably do since you're interested in these 6 month old >> patches, some insight would be appreciated! > > Assuming we don't go with hwcap, I dont think the order of the > riscv_isa_ext_id enum matters that much? The chief put it in canonical order so that's good enough for me! > > iiuc we're building the cpuinfo string from the riscv_isa_ext_data > array, and I think the current code is incorrect: > > static struct riscv_isa_ext_data isa_ext_arr[] = { > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), > __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), > __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), > __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), > __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), > __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), > }; > > zicbom and zihintpause should come before supervisor level extensions. > I'm going to send a patch for that. idk, Palmer explicitly re-ordered this: https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/ By my reading of the isa manual, what Palmer did is correct as those are not "Additional Standard Extensions". /shrug > > And the Zb/Zk ones should come after the Zi ones, and before the > supervisor level ones (The I category comes before the B or the K one). This I agree with though. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 17:20 ` Conor Dooley @ 2022-11-24 17:34 ` Samuel Ortiz 2022-11-24 17:54 ` Conor Dooley 0 siblings, 1 reply; 15+ messages in thread From: Samuel Ortiz @ 2022-11-24 17:34 UTC (permalink / raw) To: Conor Dooley Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On Thu, Nov 24, 2022 at 05:20:37PM +0000, Conor Dooley wrote: > On 24/11/2022 17:12, Samuel Ortiz wrote: > > [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote: > >> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote: > >> > >>> Patch #1 is definitely needed regardless of which interface we pick for > >>> exposing the ISA strings to userspace. > >> > >> I took another look at #1, and I feel more confused about what > >> constitutes canonical order than I did before! If you know better than > >> I, and you probably do since you're interested in these 6 month old > >> patches, some insight would be appreciated! > > > > Assuming we don't go with hwcap, I dont think the order of the > > riscv_isa_ext_id enum matters that much? > > The chief put it in canonical order so that's good enough for me! > > > > > iiuc we're building the cpuinfo string from the riscv_isa_ext_data > > array, and I think the current code is incorrect: > > > > static struct riscv_isa_ext_data isa_ext_arr[] = { > > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > > __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), > > __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), > > __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), > > __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), > > __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), > > __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), > > }; > > > > zicbom and zihintpause should come before supervisor level extensions. > > I'm going to send a patch for that. > > idk, Palmer explicitly re-ordered this: > https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/ > > By my reading of the isa manual, what Palmer did is correct as > those are not "Additional Standard Extensions". /shrug Hmm, by their name (Z[a-b]+) they are Additional Standard Extensions. What am I missing? Cheers, Samuel. > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 17:34 ` Samuel Ortiz @ 2022-11-24 17:54 ` Conor Dooley 2022-11-24 18:09 ` Samuel Ortiz 0 siblings, 1 reply; 15+ messages in thread From: Conor Dooley @ 2022-11-24 17:54 UTC (permalink / raw) To: Samuel Ortiz Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On 24/11/2022 17:34, Samuel Ortiz wrote: > On Thu, Nov 24, 2022 at 05:20:37PM +0000, Conor Dooley wrote: >> On 24/11/2022 17:12, Samuel Ortiz wrote: >>> [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote: >>>> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote: >>>> >>>>> Patch #1 is definitely needed regardless of which interface we pick for >>>>> exposing the ISA strings to userspace. >>>> >>>> I took another look at #1, and I feel more confused about what >>>> constitutes canonical order than I did before! If you know better than >>>> I, and you probably do since you're interested in these 6 month old >>>> patches, some insight would be appreciated! >>> >>> Assuming we don't go with hwcap, I dont think the order of the >>> riscv_isa_ext_id enum matters that much? >> >> The chief put it in canonical order so that's good enough for me! >> >>> >>> iiuc we're building the cpuinfo string from the riscv_isa_ext_data >>> array, and I think the current code is incorrect: >>> >>> static struct riscv_isa_ext_data isa_ext_arr[] = { >>> __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), >>> __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), >>> __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), >>> __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), >>> __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), >>> __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), >>> __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), >>> }; >>> >>> zicbom and zihintpause should come before supervisor level extensions. >>> I'm going to send a patch for that. >> >> idk, Palmer explicitly re-ordered this: >> https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/ >> >> By my reading of the isa manual, what Palmer did is correct as >> those are not "Additional Standard Extensions". /shrug > > Hmm, by their name (Z[a-b]+) they are Additional Standard Extensions. > What am I missing? Right, and this is where I get confused. Zam and Ztso *are* Additional Standard Extensions, I think we can agree on that one? For those extensions: \chapter{``Ztso'' Standard Extension for Total Store Ordering, v0.1} \chapter{``Zam'' Standard Extension for Misaligned Atomics, v0.1} They're also called out specifically in the table: https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L147 For Zihintpause however: \chapter{``Zihintpause'' Pause Hint, Version 2.0} See what I mean? I looked at the specs for the bitmanip stuff and for crypto, which both never mention being standard. That table has the caption: > The table also defines the canonical order in which extension names > must appear in the name string, with top-to-bottom in table > indicating first-to-last in the name string. It only calls out Zicsr, Zifencei, Zam and Ztso are being permitted before Sdef, but as I said I am not a specs person, so perhaps some of the extensions in question are intended to go there but have not yet been merged into the isa manual doc. Zihintpause *is* in the isa manual though but not specifically called out. Anyways, hopefully that at least helps with my line of thinking! Conor. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto 2022-11-24 17:54 ` Conor Dooley @ 2022-11-24 18:09 ` Samuel Ortiz 0 siblings, 0 replies; 15+ messages in thread From: Samuel Ortiz @ 2022-11-24 18:09 UTC (permalink / raw) To: Conor Dooley Cc: Hongren (Zenithal) Zheng, Palmer Dabbelt, Paul Walmsley, Albert Ou, Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner On Thu, Nov 24, 2022 at 05:54:00PM +0000, Conor Dooley wrote: > On 24/11/2022 17:34, Samuel Ortiz wrote: > > On Thu, Nov 24, 2022 at 05:20:37PM +0000, Conor Dooley wrote: > >> On 24/11/2022 17:12, Samuel Ortiz wrote: > >>> [You don't often get email from sameo@rivosinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > >>> > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >>> > >>> On Thu, Nov 24, 2022 at 11:55:01AM +0000, Conor Dooley wrote: > >>>> On Thu, Nov 24, 2022 at 11:47:30AM +0100, Samuel Ortiz wrote: > >>>> > >>>>> Patch #1 is definitely needed regardless of which interface we pick for > >>>>> exposing the ISA strings to userspace. > >>>> > >>>> I took another look at #1, and I feel more confused about what > >>>> constitutes canonical order than I did before! If you know better than > >>>> I, and you probably do since you're interested in these 6 month old > >>>> patches, some insight would be appreciated! > >>> > >>> Assuming we don't go with hwcap, I dont think the order of the > >>> riscv_isa_ext_id enum matters that much? > >> > >> The chief put it in canonical order so that's good enough for me! > >> > >>> > >>> iiuc we're building the cpuinfo string from the riscv_isa_ext_data > >>> array, and I think the current code is incorrect: > >>> > >>> static struct riscv_isa_ext_data isa_ext_arr[] = { > >>> __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), > >>> __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), > >>> __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), > >>> __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), > >>> __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), > >>> __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), > >>> __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), > >>> }; > >>> > >>> zicbom and zihintpause should come before supervisor level extensions. > >>> I'm going to send a patch for that. > >> > >> idk, Palmer explicitly re-ordered this: > >> https://lore.kernel.org/linux-riscv/20220920204518.10988-1-palmer@rivosinc.com/ > >> > >> By my reading of the isa manual, what Palmer did is correct as > >> those are not "Additional Standard Extensions". /shrug > > > > Hmm, by their name (Z[a-b]+) they are Additional Standard Extensions. > > What am I missing? > > Right, and this is where I get confused. Zam and Ztso *are* Additional > Standard Extensions, I think we can agree on that one? For those > extensions: > \chapter{``Ztso'' Standard Extension for Total Store Ordering, v0.1} > \chapter{``Zam'' Standard Extension for Misaligned Atomics, v0.1} > > They're also called out specifically in the table: > https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L147 > > For Zihintpause however: > \chapter{``Zihintpause'' Pause Hint, Version 2.0} > > See what I mean? I looked at the specs for the bitmanip stuff and for > crypto, which both never mention being standard. I *think* this is because Zihintpause, bitmap and crypto are ratified but not yet part of an official spec (non-draft) release? > That table has the caption: > > The table also defines the canonical order in which extension names > > must appear in the name string, with top-to-bottom in table > > indicating first-to-last in the name string. > > It only calls out Zicsr, Zifencei, Zam and Ztso are being permitted > before Sdef, but as I said I am not a specs person, so perhaps some > of the extensions in question are intended to go there but have not > yet been merged into the isa manual doc. Zihintpause *is* in the > isa manual though but not specifically called out. > > Anyways, hopefully that at least helps with my line of thinking! It does, thanks. It's a little confusing, I agree. Cheers, Samuel. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v3 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT 2022-06-12 18:44 [PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Hongren (Zenithal) Zheng 2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng 2022-06-12 18:46 ` [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto Hongren (Zenithal) Zheng @ 2022-06-12 18:47 ` Hongren (Zenithal) Zheng 2 siblings, 0 replies; 15+ messages in thread From: Hongren (Zenithal) Zheng @ 2022-06-12 18:47 UTC (permalink / raw) To: Palmer Dabbelt, Paul Walmsley, Albert Ou Cc: Atish Patra, Anup Patel, Eric Biederman, Kees Cook, linux-mm, linux-riscv, linux-kernel, linux-api, Michael Kerrisk, linux-man, Jiatai He, Heiko Stuebner, Conor.Dooley One viable way to detect Zb/Zk HWCAP is from the DT binding. No matter how the "M" mode things change, this way can always be an auxiliary way to detect it. Note that QEMU currently has "zba/zbb/zbc/zbs" in their device tree riscv,isa This also fixes the isa2hwcap way as using unsigned char for long extension is not viable. Note that the tolower function ensures functionality. For other no-hwcap extension (e.g. h, s, u), or ("|") with 0 has no effect on hwcap. Tested-by: Jiatai He <jiatai2021@iscas.ac.cn> Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> --- arch/riscv/include/asm/elf.h | 2 ++ arch/riscv/include/asm/hwcap.h | 2 ++ arch/riscv/kernel/cpufeature.c | 48 ++++++++++++++++++++++++++-------- 3 files changed, 41 insertions(+), 11 deletions(-) diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h index 14fc7342490b..cbf70c5ac1a4 100644 --- a/arch/riscv/include/asm/elf.h +++ b/arch/riscv/include/asm/elf.h @@ -65,7 +65,9 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); * but it's not easy, and we've already done it here. */ #define ELF_HWCAP (elf_hwcap) +#define ELF_HWCAP2 (elf_hwcap2) extern unsigned long elf_hwcap; +extern unsigned long elf_hwcap2; /* * This yields a string that ld.so will use to load implementation diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index 02c454a12683..ef0349c5d303 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -17,12 +17,14 @@ * instruction set this cpu supports. */ #define ELF_HWCAP (elf_hwcap) +#define ELF_HWCAP2 (elf_hwcap2) enum { CAP_HWCAP = 1, }; extern unsigned long elf_hwcap; +extern unsigned long elf_hwcap2; #define RISCV_ISA_EXT_a ('a' - 'a') #define RISCV_ISA_EXT_c ('c' - 'a') diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 0c2638365ec2..40a5ab3962f0 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -23,6 +23,7 @@ #define NUM_ALPHA_EXTS ('z' - 'a' + 1) unsigned long elf_hwcap __read_mostly; +unsigned long elf_hwcap2 __read_mostly; /* Host ISA bitmap */ static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly; @@ -74,21 +75,39 @@ void __init riscv_fill_hwcap(void) const char *isa; char print_str[NUM_ALPHA_EXTS + 1]; int i, j; - static unsigned long isa2hwcap[256] = {0}; - - isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; - isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; - isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; - isa2hwcap['f'] = isa2hwcap['F'] = COMPAT_HWCAP_ISA_F; - isa2hwcap['d'] = isa2hwcap['D'] = COMPAT_HWCAP_ISA_D; - isa2hwcap['c'] = isa2hwcap['C'] = COMPAT_HWCAP_ISA_C; + static unsigned long isa2hwcap[RISCV_ISA_EXT_MAX] = {0}; + + /* HWCAP */ + isa2hwcap[RISCV_ISA_EXT_i] = COMPAT_HWCAP_ISA_I; + isa2hwcap[RISCV_ISA_EXT_m] = COMPAT_HWCAP_ISA_M; + isa2hwcap[RISCV_ISA_EXT_a] = COMPAT_HWCAP_ISA_A; + isa2hwcap[RISCV_ISA_EXT_f] = COMPAT_HWCAP_ISA_F; + isa2hwcap[RISCV_ISA_EXT_d] = COMPAT_HWCAP_ISA_D; + isa2hwcap[RISCV_ISA_EXT_c] = COMPAT_HWCAP_ISA_C; + /* HWCAP2 */ + isa2hwcap[RISCV_ISA_EXT_ZBA] = COMPAT_HWCAP2_ISA_ZBA; + isa2hwcap[RISCV_ISA_EXT_ZBB] = COMPAT_HWCAP2_ISA_ZBB; + isa2hwcap[RISCV_ISA_EXT_ZBC] = COMPAT_HWCAP2_ISA_ZBC; + isa2hwcap[RISCV_ISA_EXT_ZBS] = COMPAT_HWCAP2_ISA_ZBS; + isa2hwcap[RISCV_ISA_EXT_ZBKB] = COMPAT_HWCAP2_ISA_ZBKB; + isa2hwcap[RISCV_ISA_EXT_ZBKC] = COMPAT_HWCAP2_ISA_ZBKC; + isa2hwcap[RISCV_ISA_EXT_ZBKX] = COMPAT_HWCAP2_ISA_ZBKX; + isa2hwcap[RISCV_ISA_EXT_ZKNE] = COMPAT_HWCAP2_ISA_ZKND; + isa2hwcap[RISCV_ISA_EXT_ZKND] = COMPAT_HWCAP2_ISA_ZKNE; + isa2hwcap[RISCV_ISA_EXT_ZKNH] = COMPAT_HWCAP2_ISA_ZKNH; + isa2hwcap[RISCV_ISA_EXT_ZKSED] = COMPAT_HWCAP2_ISA_ZKSED; + isa2hwcap[RISCV_ISA_EXT_ZKSH] = COMPAT_HWCAP2_ISA_ZKSH; + isa2hwcap[RISCV_ISA_EXT_ZKR] = COMPAT_HWCAP2_ISA_ZKR; + isa2hwcap[RISCV_ISA_EXT_ZKT] = COMPAT_HWCAP2_ISA_ZKT; elf_hwcap = 0; + elf_hwcap2 = 0; bitmap_zero(riscv_isa, RISCV_ISA_EXT_MAX); for_each_of_cpu_node(node) { unsigned long this_hwcap = 0; + unsigned long this_hwcap2 = 0; DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX); const char *temp; @@ -187,15 +206,17 @@ void __init riscv_fill_hwcap(void) #define SET_ISA_EXT_MAP(name, bit) \ do { \ if ((ext_end - ext == sizeof(name) - 1) && \ - !memcmp(ext, name, sizeof(name) - 1)) \ + !memcmp(ext, name, sizeof(name) - 1)) { \ + this_hwcap2 |= isa2hwcap[bit]; \ set_bit(bit, this_isa); \ + } \ } while (false) \ if (unlikely(ext_err)) continue; if (!ext_long) { - this_hwcap |= isa2hwcap[(unsigned char)(*ext)]; - set_bit(*ext - 'a', this_isa); + this_hwcap |= isa2hwcap[tolower(*ext) - 'a']; + set_bit(tolower(*ext) - 'a', this_isa); } else { SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); @@ -246,6 +267,11 @@ void __init riscv_fill_hwcap(void) else elf_hwcap = this_hwcap; + if (elf_hwcap2) + elf_hwcap2 &= this_hwcap2; + else + elf_hwcap2 = this_hwcap2; + if (bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX)) bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX); else -- 2.35.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-11-24 18:09 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-12 18:44 [PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Hongren (Zenithal) Zheng 2022-06-12 18:46 ` [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng 2022-11-24 9:19 ` Samuel Ortiz 2022-11-24 11:53 ` Conor Dooley 2022-06-12 18:46 ` [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto Hongren (Zenithal) Zheng 2022-11-24 9:30 ` Samuel Ortiz 2022-11-24 9:58 ` Conor Dooley 2022-11-24 10:47 ` Samuel Ortiz 2022-11-24 11:55 ` Conor Dooley 2022-11-24 17:12 ` Samuel Ortiz 2022-11-24 17:20 ` Conor Dooley 2022-11-24 17:34 ` Samuel Ortiz 2022-11-24 17:54 ` Conor Dooley 2022-11-24 18:09 ` Samuel Ortiz 2022-06-12 18:47 ` [PATCH v3 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT Hongren (Zenithal) Zheng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).