[PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP

[PATCH v3 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP

[Hongren (Zenithal) Zheng]

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

[PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT

[Hongren (Zenithal) Zheng]

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

[PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Hongren (Zenithal) Zheng]

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

[PATCH v3 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT

[Hongren (Zenithal) Zheng]

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

Re: [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT

[Samuel Ortiz]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Samuel Ortiz]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Conor Dooley]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Samuel Ortiz]

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

Re: [PATCH v3 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT

[Conor Dooley]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Conor Dooley]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Samuel Ortiz]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Conor Dooley]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Samuel Ortiz]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Conor Dooley]

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

Re: [PATCH v3 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto

[Samuel Ortiz]

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