On Thu, 09 May 2024 09:26:56 PDT (-0700), andy.chiu@xxxxxxxxxx wrote:
The following Vector subextensions for "embedded" platforms are added
into RISCV_HWPROBE_KEY_IMA_EXT_0:
- ZVE32X
- ZVE32F
- ZVE64X
- ZVE64F
- ZVE64D
Extensions ending with an X indicates that the platform doesn't have a
vector FPU.
Extensions ending with F/D mean that whether single (F) or double (D)
precision vector operation is supported.
The number 32 or 64 follows from ZVE tells the maximum element length.
Signed-off-by: Andy Chiu <andy.chiu@xxxxxxxxxx>
Reviewed-by: Clément Léger <cleger@xxxxxxxxxxxx>
---
Changelog v5:
- Rebase thus add ZVE32X after RISCV_HWPROBE_EXT_ZICOND.
Changelog v2:
- zve* extensions in hwprobe depends on whether kernel supports v, so
include them after has_vector(). Fix a typo. (Clément)
---
Documentation/arch/riscv/hwprobe.rst | 15 +++++++++++++++
arch/riscv/include/uapi/asm/hwprobe.h | 5 +++++
arch/riscv/kernel/sys_hwprobe.c | 5 +++++
3 files changed, 25 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 204cd4433af5..fc015b452ebf 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -192,6 +192,21 @@ The following keys are defined:
supported as defined in the RISC-V ISA manual starting from commit
d8ab5c78c207 ("Zihintpause is ratified").
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE32F`: The Vector sub-extension Zve32f is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE64X`: The Vector sub-extension Zve64x is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE64F`: The Vector sub-extension Zve64f is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE64D`: The Vector sub-extension Zve64d is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
information about the selected set of processors.
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 31c570cbd1c5..6593aedb9d2b 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -60,6 +60,11 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZACAS (1ULL << 34)
#define RISCV_HWPROBE_EXT_ZICOND (1ULL << 35)
#define RISCV_HWPROBE_EXT_ZIHINTPAUSE (1ULL << 36)
+#define RISCV_HWPROBE_EXT_ZVE32X (1ULL << 37)
+#define RISCV_HWPROBE_EXT_ZVE32F (1ULL << 38)
+#define RISCV_HWPROBE_EXT_ZVE64X (1ULL << 39)
+#define RISCV_HWPROBE_EXT_ZVE64F (1ULL << 40)
+#define RISCV_HWPROBE_EXT_ZVE64D (1ULL << 41)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 969ef3d59dbe..35390b4a5a17 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -114,6 +114,11 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
EXT_KEY(ZIHINTPAUSE);
if (has_vector()) {
+ EXT_KEY(ZVE32X);
+ EXT_KEY(ZVE32F);
+ EXT_KEY(ZVE64X);
+ EXT_KEY(ZVE64F);
+ EXT_KEY(ZVE64D);
EXT_KEY(ZVBB);
EXT_KEY(ZVBC);
EXT_KEY(ZVKB);
Conor left a comment over here
<https://lore.kernel.org/all/20240510-zve-detection-v5-6-0711bdd26c12@xxxxxxxxxx/>.
I think the best bet is to just merge this v5 on for-next now, though --
there's a bunch of patch sets touching ISA string parsing and IIUC that
sub-extension parsing stuff is a pre-existing issue, and Clement's patch
set still has some outstanding feedback to address.
So I think if we just go with this we're not regressing anything, we
just have a bit more to clean up. Maybe it's a little uglier now that
userspace can see the sub-extensions, but I'd bet wacky ISA strings will
be able to confuse us for a while.
I staged this so I can throw it at the tester, LMK if anyone has issues
otherwise it'll show up on for-next.
