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
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
This commit 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 commit 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 <[email protected]>
Signed-off-by: Hongren (Zenithal) Zheng <[email protected]>
---
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 40c8776aec12..9d2bed2c1a37 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 dea3ea19deee..800a7aebced3 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
userspace currently lacks a way to detect whether the
platform has Bitmanip/Scalar Crypto capability,
this commit provides a way 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
Userspace currently has to use env var to detect them.
This commit along does not assume any specific mechanism
below kernel.
Tested-by: Jiatai He <[email protected]>
Signed-off-by: Hongren (Zenithal) Zheng <[email protected]>
---
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
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 <[email protected]>
Signed-off-by: Hongren (Zenithal) Zheng <[email protected]>
---
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 f53c40026c7a..c6a4d8d2a241 100644
--- a/arch/riscv/include/asm/elf.h
+++ b/arch/riscv/include/asm/elf.h
@@ -51,7 +51,9 @@
* 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 800a7aebced3..03ea199edffc 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_weight(riscv_isa, RISCV_ISA_EXT_MAX))
bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
else
--
2.35.1
On Wed, May 18, 2022 at 09:39:53AM +0000, [email protected] wrote:
> On 18/05/2022 10:25, Hongren (Zenithal) Zheng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > userspace currently lacks a way to detect whether the
> > platform has Bitmanip/Scalar Crypto capability,
> > this commit provides a way 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
> > Userspace currently has to use env var to detect them.
> >
> > This commit along does not assume any specific mechanism
> > below kernel.
>
> s/along/alone?
Thanks for catching this typo!
>
> But I think you could rewrite this sentence to make it
> clearer, I had to read it more than once to see if that was
> actually a typo or not.
> Possibly swap "This commit" for "This interface" or similar,
> both here and in the first paragraph.
> Maybe something like:
>
> "This interface does not make any assumptions about the
> underlying hardware"
Will use this kind of description in the next version.
>
> Thanks,
> Conor.
On Wed, May 18, 2022 at 09:50:18AM +0000, [email protected] wrote:
> On 18/05/2022 10:25, Hongren (Zenithal) Zheng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > This commit parses Zb/Zk related string from DT and
> > output them in cpuinfo
>
> Similarly here, the typical "this patch" comment.
Will fix in the next version.
>
> >
> > 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 commit also changes the logical id of
>
> "also" makes it sound like this a separate change?
> If so, split it into another patch.
No, adding Zba naturally changes the logical id.
I think it would be strange the first patch appends Zba
then the second patch moves Zba to the beginning of the list
>
> > 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 <[email protected]>
> > Signed-off-by: Hongren (Zenithal) Zheng <[email protected]>