In order to be able to gather more information about the supported ISA
extensions from userspace using the hwprobe syscall, add more ISA extensions
report. This series adds the following ISA extensions parsing support:
- Zfh[min]
- Zvfh[min]
- Zihintntl
- Zbc
- Zvbb
- Zvbc
- Zvkb
- Zvkg
- Zvkned
- Zvknh[ab]
- Zvksed
- Zvksh
- Zvkn
- Zvknc
- Zvkng
- Zvks
- Zvksc
- Zvksg
- Zvkt
- Zfa
- Zbkb
- Zbkc
- Zbkx
- Zknd
- Zkne
- Zknh
- Zkr
- Zksed
- Zksh
- Zkt
Some of these extensions are actually shorthands for other "sub"
extensions. This series includes a patch from Conor/Evan that adds a way
to specify such "bundled" extensions. When exposing these bundled
extensions to userspace through hwprobe, only the "sub" extensions are
exposed.
In order to test it, one can use qemu and the small hwprobe utility
provided[1]. Run qemu by specifying additional ISA extensions, for
instance:
$ qemu-system-riscv64 -cpu rv64,v=true,zk=true,zvksh=true,zvkned=true
<whatever options you want>
Then, run hwprobe_dump:
$ ./hwprobe_dump
Base system ISA:
- IMA_FD
- C
- V
Supported extensions:
- Zba
- Zbb
- Zbs
- Zbc
- Zbkb
- Zbkc
- Zbkx
- Zknd
- Zkne
- Zknh
- Zkt
- Zvkned
- Zvksh
- Zihintntl
- Zfa
Link: https://github.com/clementleger/hwprobe_dump [1]
---
Changes in V2:
- Fix typo in first commit title (fatorize->factorize)
- Add Zfa support
- Fix missing uppercase for Zvkt naming in dt-bindings
- Add Conor Acked-by on dt-bindings commits
- Add scalar crypto support from Conor/Evan.
- Use reporting of bunbled extensions for vector crypto
Clément Léger (18):
riscv: hwprobe: factorize hwprobe ISA extension reporting
riscv: hwprobe: add support for scalar crypto ISA extensions
dt-bindings: riscv: add scalar crypto ISA extensions description
riscv: add ISA extension parsing for vector crypto extensions
riscv: hwprobe: export vector crypto ISA extensions
dt-bindings: riscv: add vector crypto ISA extensions description
riscv: add ISA extension parsing for Zfh/Zfhmin
riscv: hwprobe: export Zfh/Zfhmin ISA extensions
dt-bindings: riscv: add Zfh[min] ISA extensions description
riscv: add ISA extension parsing for Zihintntl
riscv: hwprobe: export Zhintntl ISA extension
dt-bindings: riscv: add Zihintntl ISA extension description
riscv: add ISA extension parsing for Zvfh[min]
riscv: hwprobe: export Zvfh[min] ISA extensions
dt-bindings: riscv: add Zvfh[min] ISA extension description
riscv: add ISA extension parsing for Zfa
riscv: hwprobe: export Zfa ISA extension
dt-bindings: riscv: add Zfa ISA extension description
Evan Green (1):
riscv: add ISA extension parsing for scalar crypto
.../devicetree/bindings/riscv/extensions.yaml | 210 ++++++++++++++++++
Documentation/riscv/hwprobe.rst | 81 +++++++
arch/riscv/include/asm/hwcap.h | 33 ++-
arch/riscv/include/uapi/asm/hwprobe.h | 26 +++
arch/riscv/kernel/cpufeature.c | 165 ++++++++++++--
arch/riscv/kernel/sys_riscv.c | 64 ++++--
6 files changed, 543 insertions(+), 36 deletions(-)
--
2.42.0
Factorize ISA extension reporting by using a macro rather than
copy/pasting extension names. This will allow adding new extensions more
easily.
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 473159b5f303..e207874e686e 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
for_each_cpu(cpu, cpus) {
struct riscv_isainfo *isainfo = &hart_isa[cpu];
- if (riscv_isa_extension_available(isainfo->isa, ZBA))
- pair->value |= RISCV_HWPROBE_EXT_ZBA;
- else
- missing |= RISCV_HWPROBE_EXT_ZBA;
-
- if (riscv_isa_extension_available(isainfo->isa, ZBB))
- pair->value |= RISCV_HWPROBE_EXT_ZBB;
- else
- missing |= RISCV_HWPROBE_EXT_ZBB;
-
- if (riscv_isa_extension_available(isainfo->isa, ZBS))
- pair->value |= RISCV_HWPROBE_EXT_ZBS;
- else
- missing |= RISCV_HWPROBE_EXT_ZBS;
+#define CHECK_ISA_EXT(__ext) \
+ do { \
+ if (riscv_isa_extension_available(isainfo->isa, __ext)) \
+ pair->value |= RISCV_HWPROBE_EXT_##__ext; \
+ else \
+ missing |= RISCV_HWPROBE_EXT_##__ext; \
+ } while (false)
+
+ /*
+ * Only use CHECK_ISA_EXT() for extensions which can be exposed
+ * to userspace, regardless of the kernel's configuration, as no
+ * other checks, besides presence in the hart_isa bitmap, are
+ * made.
+ */
+ CHECK_ISA_EXT(ZBA);
+ CHECK_ISA_EXT(ZBB);
+ CHECK_ISA_EXT(ZBS);
+#undef CHECK_ISA_EXT
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.42.0
Add description for scalar crypto ISA extensions which can now be
reported through hwprobe for userspace usage. These extensions are the
following:
- Zbkb
- Zbkc
- Zbkx
- Zknd
- Zkne
- Zknh
- Zkr
- Zksed
- Zksh
- Zkt
Signed-off-by: Clément Léger <[email protected]>
---
.../devicetree/bindings/riscv/extensions.yaml | 77 +++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index cc1f546fdbdc..96ed3d22d3c4 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -184,12 +184,89 @@ properties:
multiplication as ratified at commit 6d33919 ("Merge pull request
#158 from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+ - const: zbkb
+ description:
+ The standard Zbkb bitmanip instructions for cryptography as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zbkc
+ description:
+ The standard Zbkc carry-less multiply instructions as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zbkx
+ description:
+ The standard Zbkx crossbar permutation instructions as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
- const: zbs
description: |
The standard Zbs bit-manipulation extension for single-bit
instructions as ratified at commit 6d33919 ("Merge pull request #158
from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+ - const: zk
+ description:
+ The standard Zk Standard Scalar cryptography extension as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zkn
+ description:
+ The standard Zkn NIST algorithm suite extensions as ratified in
+ version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zknd
+ description: |
+ The standard Zknd for NIST suite: AES decryption instructions as
+ ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zkne
+ description: |
+ The standard Zkne for NIST suite: AES encryption instructions as
+ ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zknh
+ description: |
+ The standard Zknh for NIST suite: hash function instructions as
+ ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zkr
+ description:
+ The standard Zkr entropy source extension as ratified in version
+ 1.0 of RISC-V Cryptography Extensions Volume I specification.
+
+ - const: zks
+ description:
+ The standard Zks ShangMi algorithm suite extensions as ratified in
+ version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zksed
+ description: |
+ The standard Zksed for ShangMi suite: SM4 block cipher instructions
+ as ratified in version 1.0 of RISC-V Cryptography Extensions
+ Volume I specification.
+
+ - const: zksh
+ description: |
+ The standard Zksh for ShangMi suite: SM3 hash function instructions
+ as ratified in version 1.0 of RISC-V Cryptography Extensions
+ Volume I specification.
+
+ - const: zkt
+ description:
+ The standard Zkt for data independent execution latency as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
- const: zicbom
description:
The standard Zicbom extension for base cache management operations as
--
2.42.0
Add parsing of some Zv* vector crypto ISA extensions that are mentioned
in "RISC-V Cryptography Extensions Volume II" [1]. These ISA extensions
are the following:
- Zvbb: Vector Basic Bit-manipulation
- Zvbc: Vector Carryless Multiplication
- Zvkb: Vector Cryptography Bit-manipulation
- Zvkg: Vector GCM/GMAC.
- Zvkned: NIST Suite: Vector AES Block Cipher
- Zvknh[ab]: NIST Suite: Vector SHA-2 Secure Hash
- Zvksed: ShangMi Suite: SM4 Block Cipher
- Zvksh: ShangMi Suite: SM3 Secure Hash
- Zvkn: NIST Algorithm Suite
- Zvknc: NIST Algorithm Suite with carryless multiply
- Zvkng: NIST Algorithm Suite with GCM.
- Zvks: ShangMi Algorithm Suite
- Zvksc: ShangMi Algorithm Suite with carryless multiplication
- Zvksg: ShangMi Algorithm Suite with GCM.
- Zvkt: Vector Data-Independent Execution Latency.
Link: https://drive.google.com/file/d/1gb9OLH-DhbCgWp7VwpPOVrrY6f3oSJLL/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/include/asm/hwcap.h | 10 ++++++
arch/riscv/kernel/cpufeature.c | 56 ++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index ab80d822c847..a2fac23b0cc0 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -69,6 +69,16 @@
#define RISCV_ISA_EXT_ZKSED 51
#define RISCV_ISA_EXT_ZKSH 52
#define RISCV_ISA_EXT_ZKT 53
+#define RISCV_ISA_EXT_ZVBB 54
+#define RISCV_ISA_EXT_ZVBC 55
+#define RISCV_ISA_EXT_ZVKB 56
+#define RISCV_ISA_EXT_ZVKG 57
+#define RISCV_ISA_EXT_ZVKNED 58
+#define RISCV_ISA_EXT_ZVKNHA 59
+#define RISCV_ISA_EXT_ZVKNHB 60
+#define RISCV_ISA_EXT_ZVKSED 61
+#define RISCV_ISA_EXT_ZVKSH 62
+#define RISCV_ISA_EXT_ZVKT 63
#define RISCV_ISA_EXT_MAX 64
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index d3682fdfd9f1..8cf0b8b442ae 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -144,6 +144,46 @@ static const unsigned int riscv_zks_bundled_exts[] = {
RISCV_ISA_EXT_ZKSH
};
+#define RISCV_ISA_EXT_ZVKN \
+ RISCV_ISA_EXT_ZVKNED, \
+ RISCV_ISA_EXT_ZVKNHB, \
+ RISCV_ISA_EXT_ZVKB, \
+ RISCV_ISA_EXT_ZVKT
+
+static const unsigned int riscv_zvkn_bundled_exts[] = {
+ RISCV_ISA_EXT_ZVKN
+};
+
+static const unsigned int riscv_zvknc_bundled_exts[] = {
+ RISCV_ISA_EXT_ZVKN,
+ RISCV_ISA_EXT_ZVBC,
+};
+
+static const unsigned int riscv_zvkng_bundled_exts[] = {
+ RISCV_ISA_EXT_ZVKN,
+ RISCV_ISA_EXT_ZVKG,
+};
+
+#define RISCV_ISA_EXT_ZVKS \
+ RISCV_ISA_EXT_ZVKSED, \
+ RISCV_ISA_EXT_ZVKSH, \
+ RISCV_ISA_EXT_ZVKB, \
+ RISCV_ISA_EXT_ZVKT
+
+static const unsigned int riscv_zvks_bundled_exts[] = {
+ RISCV_ISA_EXT_ZVKS
+};
+
+static const unsigned int riscv_zvksc_bundled_exts[] = {
+ RISCV_ISA_EXT_ZVKS,
+ RISCV_ISA_EXT_ZVBC,
+};
+
+static const unsigned int riscv_zvksg_bundled_exts[] = {
+ RISCV_ISA_EXT_ZVKS,
+ RISCV_ISA_EXT_ZVKG,
+};
+
/*
* The canonical order of ISA extension names in the ISA string is defined in
* chapter 27 of the unprivileged specification.
@@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
__RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
__RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
+ __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
+ __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
+ __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
+ __RISCV_ISA_EXT_DATA(zvkg, RISCV_ISA_EXT_ZVKG),
+ __RISCV_ISA_EXT_BUNDLE(zvkn, riscv_zvkn_bundled_exts),
+ __RISCV_ISA_EXT_BUNDLE(zvknc, riscv_zvknc_bundled_exts),
+ __RISCV_ISA_EXT_DATA(zvkned, RISCV_ISA_EXT_ZVKNED),
+ __RISCV_ISA_EXT_BUNDLE(zvkng, riscv_zvkng_bundled_exts),
+ __RISCV_ISA_EXT_DATA(zvknha, RISCV_ISA_EXT_ZVKNHA),
+ __RISCV_ISA_EXT_DATA(zvknhb, RISCV_ISA_EXT_ZVKNHB),
+ __RISCV_ISA_EXT_BUNDLE(zvks, riscv_zvks_bundled_exts),
+ __RISCV_ISA_EXT_BUNDLE(zvksc, riscv_zvksc_bundled_exts),
+ __RISCV_ISA_EXT_DATA(zvksed, RISCV_ISA_EXT_ZVKSED),
+ __RISCV_ISA_EXT_DATA(zvksh, RISCV_ISA_EXT_ZVKSH),
+ __RISCV_ISA_EXT_BUNDLE(zvksg, riscv_zvksg_bundled_exts),
+ __RISCV_ISA_EXT_DATA(zvkt, RISCV_ISA_EXT_ZVKT),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
--
2.42.0
Export the following scalar crypto extensions through hwprobe:
- Zbkb
- Zbkc
- Zbkx
- Zknd
- Zkne
- Zknh
- Zksed
- Zksh
- Zkt
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/riscv/hwprobe.rst | 30 +++++++++++++++++++++++++++
arch/riscv/include/uapi/asm/hwprobe.h | 10 +++++++++
arch/riscv/kernel/sys_riscv.c | 10 +++++++++
3 files changed, 50 insertions(+)
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index a52996b22f75..968895562d42 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -77,6 +77,36 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
in version 1.0 of the Bit-Manipulation ISA extensions.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined
+ in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBKB` The Zbkb extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBKC` The Zbkc extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBKX` The Zbkx extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKND` The Zknd extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKNE` The Zkne extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKNH` The Zknh extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKSED` The Zksed extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKSH` The Zksh extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKT` The Zkt extension is supported, as defined
+ in version 1.0 of the Scalar Crypto ISA extensions.
+
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
information about the selected set of processors.
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 006bfb48343d..89d0e37a01e9 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -29,6 +29,16 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZBA (1 << 3)
#define RISCV_HWPROBE_EXT_ZBB (1 << 4)
#define RISCV_HWPROBE_EXT_ZBS (1 << 5)
+#define RISCV_HWPROBE_EXT_ZBC (1 << 6)
+#define RISCV_HWPROBE_EXT_ZBKB (1 << 7)
+#define RISCV_HWPROBE_EXT_ZBKC (1 << 8)
+#define RISCV_HWPROBE_EXT_ZBKX (1 << 9)
+#define RISCV_HWPROBE_EXT_ZKND (1 << 10)
+#define RISCV_HWPROBE_EXT_ZKNE (1 << 11)
+#define RISCV_HWPROBE_EXT_ZKNH (1 << 12)
+#define RISCV_HWPROBE_EXT_ZKSED (1 << 13)
+#define RISCV_HWPROBE_EXT_ZKSH (1 << 14)
+#define RISCV_HWPROBE_EXT_ZKT (1 << 15)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index e207874e686e..2b50c661da90 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -162,6 +162,16 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
CHECK_ISA_EXT(ZBA);
CHECK_ISA_EXT(ZBB);
CHECK_ISA_EXT(ZBS);
+ CHECK_ISA_EXT(ZBC);
+ CHECK_ISA_EXT(ZBKB);
+ CHECK_ISA_EXT(ZBKC);
+ CHECK_ISA_EXT(ZBKX);
+ CHECK_ISA_EXT(ZKND);
+ CHECK_ISA_EXT(ZKNE);
+ CHECK_ISA_EXT(ZKNH);
+ CHECK_ISA_EXT(ZKSED);
+ CHECK_ISA_EXT(ZKSH);
+ CHECK_ISA_EXT(ZKT);
#undef CHECK_ISA_EXT
}
--
2.42.0
Add Zv* vector crypto extensions that were added in "RISC-V Cryptography
Extensions Volume II" specificationi[1]:
- Zvbb: Vector Basic Bit-manipulation
- Zvbc: Vector Carryless Multiplication
- Zvkb: Vector Cryptography Bit-manipulation
- Zvkg: Vector GCM/GMAC.
- Zvkned: NIST Suite: Vector AES Block Cipher
- Zvknh[ab]: NIST Suite: Vector SHA-2 Secure Hash
- Zvksed: ShangMi Suite: SM4 Block Cipher
- Zvksh: ShangMi Suite: SM3 Secure Hash
- Zvkn: NIST Algorithm Suite
- Zvknc: NIST Algorithm Suite with carryless multiply
- Zvkng: NIST Algorithm Suite with GCM.
- Zvks: ShangMi Algorithm Suite
- Zvksc: ShangMi Algorithm Suite with carryless multiplication
- Zvksg: ShangMi Algorithm Suite with GCM.
- Zvkt: Vector Data-Independent Execution Latency.
Link: https://drive.google.com/file/d/1gb9OLH-DhbCgWp7VwpPOVrrY6f3oSJLL/view [1]
Signed-off-by: Clément Léger <[email protected]>
Acked-by: Conor Dooley <[email protected]>
---
.../devicetree/bindings/riscv/extensions.yaml | 96 +++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 96ed3d22d3c4..93beb9872900 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -323,5 +323,101 @@ properties:
in commit 2e5236 ("Ztso is now ratified.") of the
riscv-isa-manual.
+ - const: zvbb
+ description:
+ The standard Zvbb extension for vectored basic bit-manipulation
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvbc
+ description:
+ The standard Zvbc extension for vectored carryless multiplication
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkb
+ description:
+ The standard Zvkb extension for vector cryptography bit-manipulation
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkg
+ description:
+ The standard Zvkg extension for vector GCM/GMAC instructions, as
+ ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc")
+ of riscv-crypto.
+
+ - const: zvkn
+ description:
+ The standard Zvkn extension for NIST algorithm suite instructions, as
+ ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc")
+ of riscv-crypto.
+
+ - const: zvknc
+ description:
+ The standard Zvknc extension for NIST algorithm suite with carryless
+ multiply instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkned
+ description:
+ The standard Zvkned extension for Vector AES block cipher
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkng
+ description:
+ The standard Zvkng extension for NIST algorithm suite with GCM
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvknha
+ description: |
+ The standard Zvknha extension for NIST suite: vector SHA-2 secure,
+ hash (SHA-256 only) instructions, as ratified in commit
+ 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvknhb
+ description: |
+ The standard Zvknhb extension for NIST suite: vector SHA-2 secure,
+ hash (SHA-256 and SHA-512) instructions, as ratified in commit
+ 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvks
+ description:
+ The standard Zvks extension for ShangMi algorithm suite
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksc
+ description:
+ The standard Zvksc extension for ShangMi algorithm suite with
+ carryless multiplication instructions, as ratified in commit 56ed795
+ ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksed
+ description: |
+ The standard Zvksed extension for ShangMi suite: SM4 block cipher
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksh
+ description: |
+ The standard Zvksh extension for ShangMi suite: SM3 secure hash
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksg
+ description:
+ The standard Zvksg extension for ShangMi algorithm suite with GCM
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkt
+ description:
+ The standard Zvkt extension for vector data-independent execution
+ latency, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
additionalProperties: true
...
--
2.42.0
Export Zfh/Zfhmin ISA extensions[1] through hwprobe only if FPU support
is available.
Link: https://drive.google.com/file/d/1z3tQQLm5ALsAD77PM0l0CHnapxWCeVzP/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/riscv/hwprobe.rst | 6 ++++++
arch/riscv/include/uapi/asm/hwprobe.h | 2 ++
arch/riscv/kernel/sys_riscv.c | 5 +++++
3 files changed, 13 insertions(+)
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 8681fb601500..35aedfff5049 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -137,6 +137,12 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZVKT`: The Zvkt extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFH`: The Zfh extension version 1.0 is supported
+ as defined in the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFHMIN`: The Zfhmin extension version 1.0 is
+ supported as defined in the RISC-V ISA 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 2529cee323db..390805c49674 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -49,6 +49,8 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZVKSED (1 << 23)
#define RISCV_HWPROBE_EXT_ZVKSH (1 << 24)
#define RISCV_HWPROBE_EXT_ZVKT (1 << 25)
+#define RISCV_HWPROBE_EXT_ZFH (1 << 26)
+#define RISCV_HWPROBE_EXT_ZFHMIN (1 << 27)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 25d35800809f..4cca8b982a7a 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -185,6 +185,11 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
CHECK_ISA_EXT(ZVKSH);
CHECK_ISA_EXT(ZVKT);
}
+
+ if (has_fpu()) {
+ CHECK_ISA_EXT(ZFH);
+ CHECK_ISA_EXT(ZFHMIN);
+ }
#undef CHECK_ISA_EXT
}
--
2.42.0
Add parsing for Zihintntl ISA extension[1] that was ratified in commit
0dc91f5 ("Zihintntl is ratified") of riscv-isa-manual[2].
Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1]
Link: https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6d [2]
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index bead05cb0df2..a9aea62b6c6f 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -81,6 +81,7 @@
#define RISCV_ISA_EXT_ZVKT 63
#define RISCV_ISA_EXT_ZFH 64
#define RISCV_ISA_EXT_ZFHMIN 65
+#define RISCV_ISA_EXT_ZIHINTNTL 66
#define RISCV_ISA_EXT_MAX 128
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 68914b5e2df9..0a74b2cdcacf 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -242,6 +242,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
__RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
__RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+ __RISCV_ISA_EXT_DATA(zihintntl, RISCV_ISA_EXT_ZIHINTNTL),
__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
__RISCV_ISA_EXT_DATA(zfh, RISCV_ISA_EXT_ZFH),
--
2.42.0
Add parsing for Zvfh/Zfhmin ISA extensions[1].
Link: https://drive.google.com/file/d/1z3tQQLm5ALsAD77PM0l0CHnapxWCeVzP/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/include/asm/hwcap.h | 4 +++-
arch/riscv/kernel/cpufeature.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index a2fac23b0cc0..bead05cb0df2 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -79,8 +79,10 @@
#define RISCV_ISA_EXT_ZVKSED 61
#define RISCV_ISA_EXT_ZVKSH 62
#define RISCV_ISA_EXT_ZVKT 63
+#define RISCV_ISA_EXT_ZFH 64
+#define RISCV_ISA_EXT_ZFHMIN 65
-#define RISCV_ISA_EXT_MAX 64
+#define RISCV_ISA_EXT_MAX 128
#ifdef CONFIG_RISCV_M_MODE
#define RISCV_ISA_EXT_SxAIA RISCV_ISA_EXT_SMAIA
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 8cf0b8b442ae..68914b5e2df9 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -244,6 +244,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+ __RISCV_ISA_EXT_DATA(zfh, RISCV_ISA_EXT_ZFH),
+ __RISCV_ISA_EXT_DATA(zfhmin, RISCV_ISA_EXT_ZFHMIN),
__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),
--
2.42.0
Add description for Zvfh[min] ISA extension[1] which can now be
reported through hwprobe for userspace usage.
Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1]
Signed-off-by: Clément Léger <[email protected]>
Acked-by: Conor Dooley <[email protected]>
---
.../devicetree/bindings/riscv/extensions.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index eb4c77b319fb..07678564f11d 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -354,6 +354,18 @@ properties:
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
+ - const: zvfh
+ description:
+ The standard Zvfh extension for vectored half-precision
+ floating-point instructions, as ratified in commit e2ccd05
+ ("Remove draft warnings from Zvfh[min]") of riscv-v-spec.
+
+ - const: zvfhmin
+ description:
+ The standard Zvfhmin extension for vectored minimal half-precision
+ floating-point instructions, as ratified in commit e2ccd05
+ ("Remove draft warnings from Zvfh[min]") of riscv-v-spec.
+
- const: zvkb
description:
The standard Zvkb extension for vector cryptography bit-manipulation
--
2.42.0
From: Evan Green <[email protected]>
The Scalar Crypto specification defines Zk as a shorthand for the
Zkn, Zkr and Zkt extensions. The same follows for both Zkn, Zks and Zbk,
which are all shorthands for various other extensions. The detailed
breakdown can be found in their dt-binding entries.
Since Zkn also implies the Zbkb, Zbkc and Zbkx extensions, simply passing
"zk" through a DT should enable all of Zbkb, Zbkc, Zbkx, Zkn, Zkr and Zkt.
For example, setting the "riscv,isa" DT property to "rv64imafdc_zk"
should generate the following cpuinfo output:
"rv64imafdc_zicntr_zicsr_zifencei_zihpm_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zkt"
riscv_isa_ext_data grows a pair of new members, to permit setting the
relevant bits for "bundled" extensions, both while parsing the ISA string
and the new dedicated extension properties
Co-developed-by: Conor Dooley <[email protected]>
Signed-off-by: Conor Dooley <[email protected]>
Signed-off-by: Evan Green <[email protected]>
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/include/asm/hwcap.h | 13 +++++
arch/riscv/kernel/cpufeature.c | 103 ++++++++++++++++++++++++++-------
2 files changed, 96 insertions(+), 20 deletions(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index b7b58258f6c7..ab80d822c847 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -58,6 +58,17 @@
#define RISCV_ISA_EXT_ZICSR 40
#define RISCV_ISA_EXT_ZIFENCEI 41
#define RISCV_ISA_EXT_ZIHPM 42
+#define RISCV_ISA_EXT_ZBC 43
+#define RISCV_ISA_EXT_ZBKB 44
+#define RISCV_ISA_EXT_ZBKC 45
+#define RISCV_ISA_EXT_ZBKX 46
+#define RISCV_ISA_EXT_ZKND 47
+#define RISCV_ISA_EXT_ZKNE 48
+#define RISCV_ISA_EXT_ZKNH 49
+#define RISCV_ISA_EXT_ZKR 50
+#define RISCV_ISA_EXT_ZKSED 51
+#define RISCV_ISA_EXT_ZKSH 52
+#define RISCV_ISA_EXT_ZKT 53
#define RISCV_ISA_EXT_MAX 64
@@ -77,6 +88,8 @@ struct riscv_isa_ext_data {
const unsigned int id;
const char *name;
const char *property;
+ const unsigned int *bundle_ids;
+ const unsigned int bundle_size;
};
extern const struct riscv_isa_ext_data riscv_isa_ext[];
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 1cfbba65d11a..d3682fdfd9f1 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -111,6 +111,39 @@ static bool riscv_isa_extension_check(int id)
.id = _id, \
}
+#define __RISCV_ISA_EXT_BUNDLE(_name, _bundled_exts) { \
+ .name = #_name, \
+ .property = #_name, \
+ .bundle_ids = _bundled_exts, \
+ .bundle_size = ARRAY_SIZE(_bundled_exts) \
+}
+
+static const unsigned int riscv_zk_bundled_exts[] = {
+ RISCV_ISA_EXT_ZBKB,
+ RISCV_ISA_EXT_ZBKC,
+ RISCV_ISA_EXT_ZBKX,
+ RISCV_ISA_EXT_ZKND,
+ RISCV_ISA_EXT_ZKNE,
+ RISCV_ISA_EXT_ZKR,
+ RISCV_ISA_EXT_ZKT,
+};
+
+static const unsigned int riscv_zkn_bundled_exts[] = {
+ RISCV_ISA_EXT_ZBKB,
+ RISCV_ISA_EXT_ZBKC,
+ RISCV_ISA_EXT_ZBKX,
+ RISCV_ISA_EXT_ZKND,
+ RISCV_ISA_EXT_ZKNE,
+ RISCV_ISA_EXT_ZKNH,
+};
+
+static const unsigned int riscv_zks_bundled_exts[] = {
+ RISCV_ISA_EXT_ZBKB,
+ RISCV_ISA_EXT_ZBKC,
+ RISCV_ISA_EXT_ZKSED,
+ RISCV_ISA_EXT_ZKSH
+};
+
/*
* The canonical order of ISA extension names in the ISA string is defined in
* chapter 27 of the unprivileged specification.
@@ -173,7 +206,21 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
__RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA),
__RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+ __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC),
+ __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB),
+ __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC),
+ __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX),
__RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS),
+ __RISCV_ISA_EXT_BUNDLE(zk, riscv_zk_bundled_exts),
+ __RISCV_ISA_EXT_BUNDLE(zkn, riscv_zkn_bundled_exts),
+ __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_BUNDLE(zks, riscv_zks_bundled_exts),
+ __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
+ __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
+ __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
@@ -185,6 +232,26 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
+static void __init match_isa_ext(const struct riscv_isa_ext_data *ext, const char *name,
+ const char *name_end, struct riscv_isainfo *isainfo)
+{
+ if ((name_end - name == strlen(ext->name)) &&
+ !strncasecmp(name, ext->name, name_end - name)) {
+ /*
+ * If this is a bundle, enable all the ISA extensions that
+ * comprise the bundle.
+ */
+ if (ext->bundle_size) {
+ for (int i = 0; i < ext->bundle_size; i++) {
+ if (riscv_isa_extension_check(ext->bundle_ids[i]))
+ set_bit(ext->bundle_ids[i], isainfo->isa);
+ }
+ } else if (riscv_isa_extension_check(ext->id)) {
+ set_bit(ext->id, isainfo->isa);
+ }
+ }
+}
+
static void __init riscv_parse_isa_string(unsigned long *this_hwcap, struct riscv_isainfo *isainfo,
unsigned long *isa2hwcap, const char *isa)
{
@@ -316,14 +383,6 @@ static void __init riscv_parse_isa_string(unsigned long *this_hwcap, struct risc
if (*isa == '_')
++isa;
-#define SET_ISA_EXT_MAP(name, bit) \
- do { \
- if ((ext_end - ext == strlen(name)) && \
- !strncasecmp(ext, name, strlen(name)) && \
- riscv_isa_extension_check(bit)) \
- set_bit(bit, isainfo->isa); \
- } while (false) \
-
if (unlikely(ext_err))
continue;
if (!ext_long) {
@@ -335,10 +394,8 @@ static void __init riscv_parse_isa_string(unsigned long *this_hwcap, struct risc
}
} else {
for (int i = 0; i < riscv_isa_ext_count; i++)
- SET_ISA_EXT_MAP(riscv_isa_ext[i].name,
- riscv_isa_ext[i].id);
+ match_isa_ext(&riscv_isa_ext[i], ext, ext_end, isainfo);
}
-#undef SET_ISA_EXT_MAP
}
}
@@ -437,18 +494,24 @@ static int __init riscv_fill_hwcap_from_ext_list(unsigned long *isa2hwcap)
}
for (int i = 0; i < riscv_isa_ext_count; i++) {
- if (of_property_match_string(cpu_node, "riscv,isa-extensions",
- riscv_isa_ext[i].property) < 0)
- continue;
+ const struct riscv_isa_ext_data ext = riscv_isa_ext[i];
- if (!riscv_isa_extension_check(riscv_isa_ext[i].id))
+ if (of_property_match_string(cpu_node, "riscv,isa-extensions",
+ ext.property) < 0)
continue;
- /* Only single letter extensions get set in hwcap */
- if (strnlen(riscv_isa_ext[i].name, 2) == 1)
- this_hwcap |= isa2hwcap[riscv_isa_ext[i].id];
-
- set_bit(riscv_isa_ext[i].id, isainfo->isa);
+ if (ext.bundle_size) {
+ for (int j = 0; j < ext.bundle_size; j++) {
+ if (riscv_isa_extension_check(ext.bundle_ids[i]))
+ set_bit(ext.bundle_ids[j], isainfo->isa);
+ }
+ } else if (riscv_isa_extension_check(ext.id)) {
+ set_bit(ext.id, isainfo->isa);
+
+ /* Only single letter extensions get set in hwcap */
+ if (strnlen(riscv_isa_ext[i].name, 2) == 1)
+ this_hwcap |= isa2hwcap[riscv_isa_ext[i].id];
+ }
}
of_node_put(cpu_node);
--
2.42.0
Add description of Zfh[min] ISA extensions[1] which can now be reported
through hwprobe for userspace usage.
Link: https://drive.google.com/file/d/1z3tQQLm5ALsAD77PM0l0CHnapxWCeVzP/view [1]
Signed-off-by: Clément Léger <[email protected]>
Acked-by: Conor Dooley <[email protected]>
---
.../devicetree/bindings/riscv/extensions.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 93beb9872900..b0a0d1bdf369 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -208,6 +208,19 @@ properties:
instructions as ratified at commit 6d33919 ("Merge pull request #158
from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+ - const: zfh
+ description:
+ The standard Zfh extension for 16-bit half-precision binary
+ floating-point instructions, as ratified in commit 64074bc ("Update
+ version numbers for Zfh/Zfinx") of riscv-isa-manual.
+
+ - const: zfhmin
+ description:
+ The standard Zfhmin extension which provides minimal support for
+ 16-bit half-precision binary floating-point instructions, as ratified
+ in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
+ riscv-isa-manual.
+
- const: zk
description:
The standard Zk Standard Scalar cryptography extension as ratified
--
2.42.0
Add description for Zihintntl ISA extension[1] which can now be reported
through hwprobe for userspace usage.
Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1]
Signed-off-by: Clément Léger <[email protected]>
Acked-by: Conor Dooley <[email protected]>
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index b0a0d1bdf369..eb4c77b319fb 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -324,6 +324,12 @@ properties:
The standard Zihintpause extension for pause hints, as ratified in
commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
+ - const: zihintntl
+ description:
+ The standard Zihintntl extension for non-temporal locality hints, as
+ ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
+ riscv-isa-manual.
+
- const: zihpm
description:
The standard Zihpm extension for hardware performance counters, as
--
2.42.0
Add description for the Zfa ISA extension[1] which can now be
reported through hwprobe for userspace usage.
Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 07678564f11d..3033afcea033 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -208,6 +208,12 @@ properties:
instructions as ratified at commit 6d33919 ("Merge pull request #158
from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+ - const: zfa
+ description:
+ The standard Zfa extension for additional floating point
+ instructions, as ratified in commit 056b6ff ("Zfa is ratified") of
+ riscv-isa-manual.
+
- const: zfh
description:
The standard Zfh extension for 16-bit half-precision binary
--
2.42.0
Export Zihintntl extension[1] through hwprobe.
Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/riscv/hwprobe.rst | 3 +++
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/sys_riscv.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 35aedfff5049..9c909e0d5316 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -143,6 +143,9 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZFHMIN`: The Zfhmin extension version 1.0 is
supported as defined in the RISC-V ISA manual.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZIHINTNTL`: The Zihintntl extension version 1.0
+ is supported as defined in the RISC-V ISA 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 390805c49674..dc4eaa978ad1 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -51,6 +51,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZVKT (1 << 25)
#define RISCV_HWPROBE_EXT_ZFH (1 << 26)
#define RISCV_HWPROBE_EXT_ZFHMIN (1 << 27)
+#define RISCV_HWPROBE_EXT_ZIHINTNTL (1 << 28)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 4cca8b982a7a..84daaf6ed4a1 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -172,6 +172,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
CHECK_ISA_EXT(ZKSED);
CHECK_ISA_EXT(ZKSH);
CHECK_ISA_EXT(ZKT);
+ CHECK_ISA_EXT(ZIHINTNTL);
if (has_vector()) {
CHECK_ISA_EXT(ZVBB);
--
2.42.0
Add parsing for Zvfh[min] ISA extension[1] which were ratified in
june 2023 around commit e2ccd0548d6c ("Remove draft warnings from
Zvfh[min]") in riscv-v-spec[2].
Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1]
Link: https://github.com/riscv/riscv-v-spec/commits/e2ccd0548d6c [2]
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/include/asm/hwcap.h | 2 ++
arch/riscv/kernel/cpufeature.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index a9aea62b6c6f..d9fb782f198d 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -82,6 +82,8 @@
#define RISCV_ISA_EXT_ZFH 64
#define RISCV_ISA_EXT_ZFHMIN 65
#define RISCV_ISA_EXT_ZIHINTNTL 66
+#define RISCV_ISA_EXT_ZVFH 67
+#define RISCV_ISA_EXT_ZVFHMIN 68
#define RISCV_ISA_EXT_MAX 128
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 0a74b2cdcacf..c70885f5014b 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -266,6 +266,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
__RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
__RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
+ __RISCV_ISA_EXT_DATA(zvfh, RISCV_ISA_EXT_ZVFH),
+ __RISCV_ISA_EXT_DATA(zvfhmin, RISCV_ISA_EXT_ZVFHMIN),
__RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
__RISCV_ISA_EXT_DATA(zvkg, RISCV_ISA_EXT_ZVKG),
__RISCV_ISA_EXT_BUNDLE(zvkn, riscv_zvkn_bundled_exts),
--
2.42.0
Export Zvfh[min] ISA extension[1] through hwprobe.
Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/riscv/hwprobe.rst | 8 ++++++++
arch/riscv/include/uapi/asm/hwprobe.h | 2 ++
arch/riscv/kernel/sys_riscv.c | 2 ++
3 files changed, 12 insertions(+)
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 9c909e0d5316..782ac26cb92a 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -146,6 +146,14 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZIHINTNTL`: The Zihintntl extension version 1.0
is supported as defined in the RISC-V ISA manual.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFH`: The Zvfh extension is supported as
+ defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
+ ("Remove draft warnings from Zvfh[min]").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFHMIN`: The Zvfhmin extension is supported as
+ defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
+ ("Remove draft warnings from Zvfh[min]").
+
* :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 dc4eaa978ad1..79407010952a 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -52,6 +52,8 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZFH (1 << 26)
#define RISCV_HWPROBE_EXT_ZFHMIN (1 << 27)
#define RISCV_HWPROBE_EXT_ZIHINTNTL (1 << 28)
+#define RISCV_HWPROBE_EXT_ZVFH (1 << 29)
+#define RISCV_HWPROBE_EXT_ZVFHMIN (1 << 30)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 84daaf6ed4a1..8d6edd721627 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -185,6 +185,8 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
CHECK_ISA_EXT(ZVKSED);
CHECK_ISA_EXT(ZVKSH);
CHECK_ISA_EXT(ZVKT);
+ CHECK_ISA_EXT(ZVFH);
+ CHECK_ISA_EXT(ZVFHMIN);
}
if (has_fpu()) {
--
2.42.0
Export Zfa ISA extension[1] through hwprobe.
Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/riscv/hwprobe.rst | 4 ++++
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/sys_riscv.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 782ac26cb92a..f81e3c93ac1e 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -154,6 +154,10 @@ The following keys are defined:
defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
("Remove draft warnings from Zvfh[min]").
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFA`: The Zfa extension is supported as
+ defined in the RISC-V ISA manual starting from commit 056b6ff467c7
+ ("Zfa is ratified").
+
* :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 79407010952a..4014492c3960 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -54,6 +54,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZIHINTNTL (1 << 28)
#define RISCV_HWPROBE_EXT_ZVFH (1 << 29)
#define RISCV_HWPROBE_EXT_ZVFHMIN (1 << 30)
+#define RISCV_HWPROBE_EXT_ZFA (1 << 31)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 8d6edd721627..a6a063f1dcf5 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -192,6 +192,7 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
if (has_fpu()) {
CHECK_ISA_EXT(ZFH);
CHECK_ISA_EXT(ZFHMIN);
+ CHECK_ISA_EXT(ZFA);
}
#undef CHECK_ISA_EXT
}
--
2.42.0
Add parsing for Zfa ISA extension [1] which were ratified in commit
056b6ff467c7 ("Zfa is ratified") of riscv-isa-manual[2].
Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1]
Link: https://github.com/riscv/riscv-isa-manual/commits/056b6ff467c7 [2]
Signed-off-by: Clément Léger <[email protected]>
---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index d9fb782f198d..8f324c646a73 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -84,6 +84,7 @@
#define RISCV_ISA_EXT_ZIHINTNTL 66
#define RISCV_ISA_EXT_ZVFH 67
#define RISCV_ISA_EXT_ZVFHMIN 68
+#define RISCV_ISA_EXT_ZFA 69
#define RISCV_ISA_EXT_MAX 128
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index c70885f5014b..296cc0025734 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -245,6 +245,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zihintntl, RISCV_ISA_EXT_ZIHINTNTL),
__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+ __RISCV_ISA_EXT_DATA(zfa, RISCV_ISA_EXT_ZFA),
__RISCV_ISA_EXT_DATA(zfh, RISCV_ISA_EXT_ZFH),
__RISCV_ISA_EXT_DATA(zfhmin, RISCV_ISA_EXT_ZFHMIN),
__RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA),
--
2.42.0
Export Zv* vector crypto ISA extensions that were added in "RISC-V
Cryptography Extensions Volume II" specification[1] through hwprobe.
This adds support for the following instructions:
- Zvbb: Vector Basic Bit-manipulation
- Zvbc: Vector Carryless Multiplication
- Zvkb: Vector Cryptography Bit-manipulation
- Zvkg: Vector GCM/GMAC.
- Zvkned: NIST Suite: Vector AES Block Cipher
- Zvknh[ab]: NIST Suite: Vector SHA-2 Secure Hash
- Zvksed: ShangMi Suite: SM4 Block Cipher
- Zvksh: ShangMi Suite: SM3 Secure Hash
- Zvknc: NIST Algorithm Suite with carryless multiply
- Zvkng: NIST Algorithm Suite with GCM.
- Zvksc: ShangMi Algorithm Suite with carryless multiplication
- Zvksg: ShangMi Algorithm Suite with GCM.
- Zvkt: Vector Data-Independent Execution Latency.
Zvkn and Zvks are ommited since they are a superset of other extensions.
Link: https://drive.google.com/file/d/1gb9OLH-DhbCgWp7VwpPOVrrY6f3oSJLL/view [1]
Signed-off-by: Clément Léger <[email protected]>
---
Documentation/riscv/hwprobe.rst | 30 +++++++++++++++++++++++++++
arch/riscv/include/uapi/asm/hwprobe.h | 10 +++++++++
arch/riscv/kernel/sys_riscv.c | 13 ++++++++++++
3 files changed, 53 insertions(+)
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 968895562d42..8681fb601500 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -107,6 +107,36 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZKT` The Zkt extension is supported, as defined
in version 1.0 of the Scalar Crypto ISA extensions.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVBB`: The Zvbb extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVBC`: The Zvbc extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKB`: The Zvkb extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKG`: The Zvkg extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKNED`: The Zvkned extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKNHA`: The Zvknha extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKNHB`: The Zvknhb extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKSED`: The Zvksed extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKSH`: The Zvksh extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKT`: The Zvkt extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
* :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 89d0e37a01e9..2529cee323db 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -39,6 +39,16 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZKSED (1 << 13)
#define RISCV_HWPROBE_EXT_ZKSH (1 << 14)
#define RISCV_HWPROBE_EXT_ZKT (1 << 15)
+#define RISCV_HWPROBE_EXT_ZVBB (1 << 16)
+#define RISCV_HWPROBE_EXT_ZVBC (1 << 17)
+#define RISCV_HWPROBE_EXT_ZVKB (1 << 18)
+#define RISCV_HWPROBE_EXT_ZVKG (1 << 19)
+#define RISCV_HWPROBE_EXT_ZVKNED (1 << 20)
+#define RISCV_HWPROBE_EXT_ZVKNHA (1 << 21)
+#define RISCV_HWPROBE_EXT_ZVKNHB (1 << 22)
+#define RISCV_HWPROBE_EXT_ZVKSED (1 << 23)
+#define RISCV_HWPROBE_EXT_ZVKSH (1 << 24)
+#define RISCV_HWPROBE_EXT_ZVKT (1 << 25)
#define RISCV_HWPROBE_KEY_CPUPERF_0 5
#define RISCV_HWPROBE_MISALIGNED_UNKNOWN (0 << 0)
#define RISCV_HWPROBE_MISALIGNED_EMULATED (1 << 0)
diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
index 2b50c661da90..25d35800809f 100644
--- a/arch/riscv/kernel/sys_riscv.c
+++ b/arch/riscv/kernel/sys_riscv.c
@@ -172,6 +172,19 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
CHECK_ISA_EXT(ZKSED);
CHECK_ISA_EXT(ZKSH);
CHECK_ISA_EXT(ZKT);
+
+ if (has_vector()) {
+ CHECK_ISA_EXT(ZVBB);
+ CHECK_ISA_EXT(ZVBC);
+ CHECK_ISA_EXT(ZVKB);
+ CHECK_ISA_EXT(ZVKG);
+ CHECK_ISA_EXT(ZVKNED);
+ CHECK_ISA_EXT(ZVKNHA);
+ CHECK_ISA_EXT(ZVKNHB);
+ CHECK_ISA_EXT(ZVKSED);
+ CHECK_ISA_EXT(ZVKSH);
+ CHECK_ISA_EXT(ZVKT);
+ }
#undef CHECK_ISA_EXT
}
--
2.42.0
On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
+ __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
+ __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVKB),
+ __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
or
+ __RISCV_ISA_EXT_BUNDLE(zvbb, riscv_zvbb_bundled_exts),
+ __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
[1]
https://github.com/riscv/riscv-crypto/blob/main/doc/vector/riscv-crypto-vector-zvkb.adoc
-Jerry
On 18/10/2023 03:45, Jerry Shih wrote:
> On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
>
> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
Hi Jerry,
Thanks for catching this, I think some other extensions will fall in
this category as well then (Zvknha/Zvknhb). I will verify that.
Clément
>
> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVKB),
> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
>
> or
>
> + __RISCV_ISA_EXT_BUNDLE(zvbb, riscv_zvbb_bundled_exts),
> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
>
> [1]
> https://github.com/riscv/riscv-crypto/blob/main/doc/vector/riscv-crypto-vector-zvkb.adoc
>
> -Jerry
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Factorize ISA extension reporting by using a macro rather than
> copy/pasting extension names. This will allow adding new extensions more
> easily.
>
> Signed-off-by: Clément Léger <[email protected]>
> ---
> arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> index 473159b5f303..e207874e686e 100644
> --- a/arch/riscv/kernel/sys_riscv.c
> +++ b/arch/riscv/kernel/sys_riscv.c
> @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> for_each_cpu(cpu, cpus) {
> struct riscv_isainfo *isainfo = &hart_isa[cpu];
>
> - if (riscv_isa_extension_available(isainfo->isa, ZBA))
> - pair->value |= RISCV_HWPROBE_EXT_ZBA;
> - else
> - missing |= RISCV_HWPROBE_EXT_ZBA;
> -
> - if (riscv_isa_extension_available(isainfo->isa, ZBB))
> - pair->value |= RISCV_HWPROBE_EXT_ZBB;
> - else
> - missing |= RISCV_HWPROBE_EXT_ZBB;
> -
> - if (riscv_isa_extension_available(isainfo->isa, ZBS))
> - pair->value |= RISCV_HWPROBE_EXT_ZBS;
> - else
> - missing |= RISCV_HWPROBE_EXT_ZBS;
> +#define CHECK_ISA_EXT(__ext) \
> + do { \
> + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
> + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
> + else \
> + missing |= RISCV_HWPROBE_EXT_##__ext; \
> + } while (false)
> +
> + /*
> + * Only use CHECK_ISA_EXT() for extensions which can be exposed
> + * to userspace, regardless of the kernel's configuration, as no
> + * other checks, besides presence in the hart_isa bitmap, are
> + * made.
This comment alludes to a dangerous trap, but I'm having trouble
understanding what it is. Perhaps some rewording to more explicitly
state the danger would be appropriate. Other than that:
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Export the following scalar crypto extensions through hwprobe:
>
> - Zbkb
> - Zbkc
> - Zbkx
> - Zknd
> - Zkne
> - Zknh
> - Zksed
> - Zksh
> - Zkt
>
> Signed-off-by: Clément Léger <[email protected]>
> ---
> Documentation/riscv/hwprobe.rst | 30 +++++++++++++++++++++++++++
> arch/riscv/include/uapi/asm/hwprobe.h | 10 +++++++++
> arch/riscv/kernel/sys_riscv.c | 10 +++++++++
> 3 files changed, 50 insertions(+)
>
> diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
> index a52996b22f75..968895562d42 100644
> --- a/Documentation/riscv/hwprobe.rst
> +++ b/Documentation/riscv/hwprobe.rst
> @@ -77,6 +77,36 @@ The following keys are defined:
> * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
> in version 1.0 of the Bit-Manipulation ISA extensions.
>
> + * :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined
> + in version 1.0 of the Scalar Crypto ISA extensions.
At least in my v1.0.1 version of the crypto scalar spec, I don't see
Zbc. That seems to be defined in the bit manipulation extensions.
On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
>
>
>
> On 18/10/2023 03:45, Jerry Shih wrote:
> > On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
> >> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> >> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
> >> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> >> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> >> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> >> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
> >> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
> >
> > The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
>
> Hi Jerry,
>
> Thanks for catching this, I think some other extensions will fall in
> this category as well then (Zvknha/Zvknhb). I will verify that.
The bundling mechanism works well when an extension is a pure lasso
around other extensions. We'd have to tweak that code if we wanted to
support cases like this, where the extension is a superset of others,
but also contains loose change not present anywhere else (and
therefore also needs to stand as a separate bit).
IMO, decomposing "pure" bundles makes sense since otherwise usermode
would have to query multiple distinct bitmaps that meant the same
thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
when an extension is a superset that also contains loose change, there
really aren't two equivalent bitmasks, each bit adds something new.
There's an argument to be made for still turning on the containing
extensions to cover for silly ISA strings (eg ISA strings that
advertise the superset but fail to advertise the containing
extensions). We can decide if we want to work that hard to cover
hypothetical broken ISA strings now, or wait until they show up.
Personally I would wait until something broken shows up. But others
may feel differently.
-Evan
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Export Zv* vector crypto ISA extensions that were added in "RISC-V
> Cryptography Extensions Volume II" specification[1] through hwprobe.
> This adds support for the following instructions:
>
> - Zvbb: Vector Basic Bit-manipulation
> - Zvbc: Vector Carryless Multiplication
> - Zvkb: Vector Cryptography Bit-manipulation
> - Zvkg: Vector GCM/GMAC.
> - Zvkned: NIST Suite: Vector AES Block Cipher
> - Zvknh[ab]: NIST Suite: Vector SHA-2 Secure Hash
> - Zvksed: ShangMi Suite: SM4 Block Cipher
> - Zvksh: ShangMi Suite: SM3 Secure Hash
> - Zvknc: NIST Algorithm Suite with carryless multiply
> - Zvkng: NIST Algorithm Suite with GCM.
> - Zvksc: ShangMi Algorithm Suite with carryless multiplication
> - Zvksg: ShangMi Algorithm Suite with GCM.
> - Zvkt: Vector Data-Independent Execution Latency.
>
> Zvkn and Zvks are ommited since they are a superset of other extensions.
s/ommited/omitted/, other than that:
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Add parsing for Zvfh/Zfhmin ISA extensions[1].
Typo: s/Zvfh/Zfh/. Other than that:
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Add parsing for Zihintntl ISA extension[1] that was ratified in commit
> 0dc91f5 ("Zihintntl is ratified") of riscv-isa-manual[2].
>
> Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1]
> Link: https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6d [2]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Export Zfh/Zfhmin ISA extensions[1] through hwprobe only if FPU support
> is available.
>
> Link: https://drive.google.com/file/d/1z3tQQLm5ALsAD77PM0l0CHnapxWCeVzP/view [1]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Add parsing for Zvfh[min] ISA extension[1] which were ratified in
> june 2023 around commit e2ccd0548d6c ("Remove draft warnings from
> Zvfh[min]") in riscv-v-spec[2].
>
> Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1]
> Link: https://github.com/riscv/riscv-v-spec/commits/e2ccd0548d6c [2]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Export Zfa ISA extension[1] through hwprobe.
>
> Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Export Zihintntl extension[1] through hwprobe.
>
> Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Add parsing for Zfa ISA extension [1] which were ratified in commit
> 056b6ff467c7 ("Zfa is ratified") of riscv-isa-manual[2].
>
> Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1]
> Link: https://github.com/riscv/riscv-isa-manual/commits/056b6ff467c7 [2]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
> >
> > Factorize ISA extension reporting by using a macro rather than
> > copy/pasting extension names. This will allow adding new extensions more
> > easily.
> >
> > Signed-off-by: Clément Léger <[email protected]>
> > ---
> > arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
> > 1 file changed, 18 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > index 473159b5f303..e207874e686e 100644
> > --- a/arch/riscv/kernel/sys_riscv.c
> > +++ b/arch/riscv/kernel/sys_riscv.c
> > @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> > for_each_cpu(cpu, cpus) {
> > struct riscv_isainfo *isainfo = &hart_isa[cpu];
> >
> > - if (riscv_isa_extension_available(isainfo->isa, ZBA))
> > - pair->value |= RISCV_HWPROBE_EXT_ZBA;
> > - else
> > - missing |= RISCV_HWPROBE_EXT_ZBA;
> > -
> > - if (riscv_isa_extension_available(isainfo->isa, ZBB))
> > - pair->value |= RISCV_HWPROBE_EXT_ZBB;
> > - else
> > - missing |= RISCV_HWPROBE_EXT_ZBB;
> > -
> > - if (riscv_isa_extension_available(isainfo->isa, ZBS))
> > - pair->value |= RISCV_HWPROBE_EXT_ZBS;
> > - else
> > - missing |= RISCV_HWPROBE_EXT_ZBS;
> > +#define CHECK_ISA_EXT(__ext) \
> > + do { \
> > + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
> > + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
> > + else \
> > + missing |= RISCV_HWPROBE_EXT_##__ext; \
> > + } while (false)
> > +
> > + /*
> > + * Only use CHECK_ISA_EXT() for extensions which can be exposed
> > + * to userspace, regardless of the kernel's configuration, as no
> > + * other checks, besides presence in the hart_isa bitmap, are
> > + * made.
>
> This comment alludes to a dangerous trap, but I'm having trouble
> understanding what it is.
You cannot, for example, use this for communicating the presence of F or
D, since they require a config option to be set before their use is
safe.
> Perhaps some rewording to more explicitly
> state the danger would be appropriate. Other than that:
>
> Reviewed-by: Evan Green <[email protected]>
On Wed, Oct 18, 2023 at 06:33:34PM +0100, Conor Dooley wrote:
> On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
> > On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
> > >
> > > Factorize ISA extension reporting by using a macro rather than
> > > copy/pasting extension names. This will allow adding new extensions more
> > > easily.
> > >
> > > Signed-off-by: Clément Léger <[email protected]>
> > > ---
> > > arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
> > > 1 file changed, 18 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > > index 473159b5f303..e207874e686e 100644
> > > --- a/arch/riscv/kernel/sys_riscv.c
> > > +++ b/arch/riscv/kernel/sys_riscv.c
> > > @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> > > for_each_cpu(cpu, cpus) {
> > > struct riscv_isainfo *isainfo = &hart_isa[cpu];
> > >
> > > - if (riscv_isa_extension_available(isainfo->isa, ZBA))
> > > - pair->value |= RISCV_HWPROBE_EXT_ZBA;
> > > - else
> > > - missing |= RISCV_HWPROBE_EXT_ZBA;
> > > -
> > > - if (riscv_isa_extension_available(isainfo->isa, ZBB))
> > > - pair->value |= RISCV_HWPROBE_EXT_ZBB;
> > > - else
> > > - missing |= RISCV_HWPROBE_EXT_ZBB;
> > > -
> > > - if (riscv_isa_extension_available(isainfo->isa, ZBS))
> > > - pair->value |= RISCV_HWPROBE_EXT_ZBS;
> > > - else
> > > - missing |= RISCV_HWPROBE_EXT_ZBS;
> > > +#define CHECK_ISA_EXT(__ext) \
> > > + do { \
> > > + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
> > > + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
> > > + else \
> > > + missing |= RISCV_HWPROBE_EXT_##__ext; \
> > > + } while (false)
> > > +
> > > + /*
> > > + * Only use CHECK_ISA_EXT() for extensions which can be exposed
> > > + * to userspace, regardless of the kernel's configuration, as no
> > > + * other checks, besides presence in the hart_isa bitmap, are
> > > + * made.
> >
> > This comment alludes to a dangerous trap, but I'm having trouble
> > understanding what it is.
>
> You cannot, for example, use this for communicating the presence of F or
> D, since they require a config option to be set before their use is
> safe.
Funnily enough, this comment is immediately contradicted by the vector
subset extensions, where these CHECK_ISA_EXT() macros are used wrapped
in has_vector(). The code looks valid to me, since has_vector() contains
the Kconfig check, but does fly in the face of this comment.
>
> > Perhaps some rewording to more explicitly
> > state the danger would be appropriate. Other than that:
> >
> > Reviewed-by: Evan Green <[email protected]>
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> Export Zvfh[min] ISA extension[1] through hwprobe.
>
> Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1]
> Signed-off-by: Clément Léger <[email protected]>
Reviewed-by: Evan Green <[email protected]>
On Wed, Oct 18, 2023 at 10:37 AM Conor Dooley <[email protected]> wrote:
>
> On Wed, Oct 18, 2023 at 06:33:34PM +0100, Conor Dooley wrote:
> > On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
> > > On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
> > > >
> > > > Factorize ISA extension reporting by using a macro rather than
> > > > copy/pasting extension names. This will allow adding new extensions more
> > > > easily.
> > > >
> > > > Signed-off-by: Clément Léger <[email protected]>
> > > > ---
> > > > arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
> > > > 1 file changed, 18 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> > > > index 473159b5f303..e207874e686e 100644
> > > > --- a/arch/riscv/kernel/sys_riscv.c
> > > > +++ b/arch/riscv/kernel/sys_riscv.c
> > > > @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> > > > for_each_cpu(cpu, cpus) {
> > > > struct riscv_isainfo *isainfo = &hart_isa[cpu];
> > > >
> > > > - if (riscv_isa_extension_available(isainfo->isa, ZBA))
> > > > - pair->value |= RISCV_HWPROBE_EXT_ZBA;
> > > > - else
> > > > - missing |= RISCV_HWPROBE_EXT_ZBA;
> > > > -
> > > > - if (riscv_isa_extension_available(isainfo->isa, ZBB))
> > > > - pair->value |= RISCV_HWPROBE_EXT_ZBB;
> > > > - else
> > > > - missing |= RISCV_HWPROBE_EXT_ZBB;
> > > > -
> > > > - if (riscv_isa_extension_available(isainfo->isa, ZBS))
> > > > - pair->value |= RISCV_HWPROBE_EXT_ZBS;
> > > > - else
> > > > - missing |= RISCV_HWPROBE_EXT_ZBS;
> > > > +#define CHECK_ISA_EXT(__ext) \
> > > > + do { \
> > > > + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
> > > > + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
> > > > + else \
> > > > + missing |= RISCV_HWPROBE_EXT_##__ext; \
> > > > + } while (false)
> > > > +
> > > > + /*
> > > > + * Only use CHECK_ISA_EXT() for extensions which can be exposed
> > > > + * to userspace, regardless of the kernel's configuration, as no
> > > > + * other checks, besides presence in the hart_isa bitmap, are
> > > > + * made.
> > >
> > > This comment alludes to a dangerous trap, but I'm having trouble
> > > understanding what it is.
> >
> > You cannot, for example, use this for communicating the presence of F or
> > D, since they require a config option to be set before their use is
> > safe.
>
> Funnily enough, this comment is immediately contradicted by the vector
> subset extensions, where these CHECK_ISA_EXT() macros are used wrapped
> in has_vector(). The code looks valid to me, since has_vector() contains
> the Kconfig check, but does fly in the face of this comment.
Ohh, got it. The word "can" is doing a lot of heavy lifting in that
comment. So maybe something like: "This macro performs little in the
way of extension-specific kernel readiness checks. It's assumed other
gating factors like required Kconfig settings have already been
confirmed to support exposing the given extension to usermode". ...
But, you know, make it sparkle.
-Evan
On 18/10/2023 19:24, Evan Green wrote:
> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>
>> Export the following scalar crypto extensions through hwprobe:
>>
>> - Zbkb
>> - Zbkc
>> - Zbkx
>> - Zknd
>> - Zkne
>> - Zknh
>> - Zksed
>> - Zksh
>> - Zkt
>>
>> Signed-off-by: Clément Léger <[email protected]>
>> ---
>> Documentation/riscv/hwprobe.rst | 30 +++++++++++++++++++++++++++
>> arch/riscv/include/uapi/asm/hwprobe.h | 10 +++++++++
>> arch/riscv/kernel/sys_riscv.c | 10 +++++++++
>> 3 files changed, 50 insertions(+)
>>
>> diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
>> index a52996b22f75..968895562d42 100644
>> --- a/Documentation/riscv/hwprobe.rst
>> +++ b/Documentation/riscv/hwprobe.rst
>> @@ -77,6 +77,36 @@ The following keys are defined:
>> * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
>> in version 1.0 of the Bit-Manipulation ISA extensions.
>>
>> + * :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined
>> + in version 1.0 of the Scalar Crypto ISA extensions.
>
> At least in my v1.0.1 version of the crypto scalar spec, I don't see
> Zbc. That seems to be defined in the bit manipulation extensions.
Thanks for catching this, this should be same than the previous line. I
will actually move the ZBC on another patch since it is not scalar crypto.
Clément
On 18/10/2023 19:36, Conor Dooley wrote:
> On Wed, Oct 18, 2023 at 06:33:34PM +0100, Conor Dooley wrote:
>> On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
>>> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>>>
>>>> Factorize ISA extension reporting by using a macro rather than
>>>> copy/pasting extension names. This will allow adding new extensions more
>>>> easily.
>>>>
>>>> Signed-off-by: Clément Léger <[email protected]>
>>>> ---
>>>> arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
>>>> 1 file changed, 18 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
>>>> index 473159b5f303..e207874e686e 100644
>>>> --- a/arch/riscv/kernel/sys_riscv.c
>>>> +++ b/arch/riscv/kernel/sys_riscv.c
>>>> @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>>>> for_each_cpu(cpu, cpus) {
>>>> struct riscv_isainfo *isainfo = &hart_isa[cpu];
>>>>
>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBA))
>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBA;
>>>> - else
>>>> - missing |= RISCV_HWPROBE_EXT_ZBA;
>>>> -
>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBB))
>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBB;
>>>> - else
>>>> - missing |= RISCV_HWPROBE_EXT_ZBB;
>>>> -
>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBS))
>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBS;
>>>> - else
>>>> - missing |= RISCV_HWPROBE_EXT_ZBS;
>>>> +#define CHECK_ISA_EXT(__ext) \
>>>> + do { \
>>>> + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
>>>> + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
>>>> + else \
>>>> + missing |= RISCV_HWPROBE_EXT_##__ext; \
>>>> + } while (false)
>>>> +
>>>> + /*
>>>> + * Only use CHECK_ISA_EXT() for extensions which can be exposed
>>>> + * to userspace, regardless of the kernel's configuration, as no
>>>> + * other checks, besides presence in the hart_isa bitmap, are
>>>> + * made.
>>>
>>> This comment alludes to a dangerous trap, but I'm having trouble
>>> understanding what it is.
>>
>> You cannot, for example, use this for communicating the presence of F or
>> D, since they require a config option to be set before their use is
>> safe.
>
> Funnily enough, this comment is immediately contradicted by the vector
> subset extensions, where these CHECK_ISA_EXT() macros are used wrapped
> in has_vector(). The code looks valid to me, since has_vector() contains
> the Kconfig check, but does fly in the face of this comment.
Yes, the KConfig checks are already done by the headers, adding #ifdef
would be redundant even if more coherent with the comment. BTW, wouldn't
it make more sense to get rid out of the unsupported extensions directly
at ISA string parsing ? ie, if kernel is compiled without V support,
then do not set the bits corresponding to these in the riscv_isa_ext[]
array ? But the initial intent was probably to be able to report the
full string through cpuinfo.
Clément
>
>>
>>> Perhaps some rewording to more explicitly
>>> state the danger would be appropriate. Other than that:
>>>
>>> Reviewed-by: Evan Green <[email protected]>
>
>
On 18/10/2023 19:26, Evan Green wrote:
> On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
>>
>>
>>
>> On 18/10/2023 03:45, Jerry Shih wrote:
>>> On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
>>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>>>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
>>>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
>>>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
>>>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
>>>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
>>>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
>>>
>>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
>>
>> Hi Jerry,
>>
>> Thanks for catching this, I think some other extensions will fall in
>> this category as well then (Zvknha/Zvknhb). I will verify that.
>
> The bundling mechanism works well when an extension is a pure lasso
> around other extensions. We'd have to tweak that code if we wanted to
> support cases like this, where the extension is a superset of others,
> but also contains loose change not present anywhere else (and
> therefore also needs to stand as a separate bit).
For Zvbb and Zvknhb, I used the following code:
static const unsigned int riscv_zvbb_bundled_exts[] = {
RISCV_ISA_EXT_ZVKB,
RISCV_ISA_EXT_ZVBB
};
static const unsigned int riscv_zvknhb_bundled_exts[] = {
RISCV_ISA_EXT_ZVKNHA,
RISCV_ISA_EXT_ZVKNHB
};
Which correctly results in both extension (superset + base set) being
enabled when only one is set. Is there something that I'm missing ?
>
> IMO, decomposing "pure" bundles makes sense since otherwise usermode
> would have to query multiple distinct bitmaps that meant the same
> thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
> maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
> when an extension is a superset that also contains loose change, there
> really aren't two equivalent bitmasks, each bit adds something new.
Agreed but if a system only report ZVBB for instance and the user wants
ZVKB, then it is clear that ZVKB should be reported as well I guess. So
in the end, it works much like "bundle" extension, just that the bundle
is actually a "real" ISA extension by itself.
Clément
>
> There's an argument to be made for still turning on the containing
> extensions to cover for silly ISA strings (eg ISA strings that
> advertise the superset but fail to advertise the containing
> extensions). We can decide if we want to work that hard to cover
> hypothetical broken ISA strings now, or wait until they show up.
> Personally I would wait until something broken shows up. But others
> may feel differently.
>
> -Evan
On 18/10/2023 19:45, Evan Green wrote:
> On Wed, Oct 18, 2023 at 10:37 AM Conor Dooley <[email protected]> wrote:
>>
>> On Wed, Oct 18, 2023 at 06:33:34PM +0100, Conor Dooley wrote:
>>> On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
>>>> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>>>>
>>>>> Factorize ISA extension reporting by using a macro rather than
>>>>> copy/pasting extension names. This will allow adding new extensions more
>>>>> easily.
>>>>>
>>>>> Signed-off-by: Clément Léger <[email protected]>
>>>>> ---
>>>>> arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
>>>>> 1 file changed, 18 insertions(+), 14 deletions(-)
>>>>>
>>>>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
>>>>> index 473159b5f303..e207874e686e 100644
>>>>> --- a/arch/riscv/kernel/sys_riscv.c
>>>>> +++ b/arch/riscv/kernel/sys_riscv.c
>>>>> @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>>>>> for_each_cpu(cpu, cpus) {
>>>>> struct riscv_isainfo *isainfo = &hart_isa[cpu];
>>>>>
>>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBA))
>>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBA;
>>>>> - else
>>>>> - missing |= RISCV_HWPROBE_EXT_ZBA;
>>>>> -
>>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBB))
>>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBB;
>>>>> - else
>>>>> - missing |= RISCV_HWPROBE_EXT_ZBB;
>>>>> -
>>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBS))
>>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBS;
>>>>> - else
>>>>> - missing |= RISCV_HWPROBE_EXT_ZBS;
>>>>> +#define CHECK_ISA_EXT(__ext) \
>>>>> + do { \
>>>>> + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
>>>>> + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
>>>>> + else \
>>>>> + missing |= RISCV_HWPROBE_EXT_##__ext; \
>>>>> + } while (false)
>>>>> +
>>>>> + /*
>>>>> + * Only use CHECK_ISA_EXT() for extensions which can be exposed
>>>>> + * to userspace, regardless of the kernel's configuration, as no
>>>>> + * other checks, besides presence in the hart_isa bitmap, are
>>>>> + * made.
>>>>
>>>> This comment alludes to a dangerous trap, but I'm having trouble
>>>> understanding what it is.
>>>
>>> You cannot, for example, use this for communicating the presence of F or
>>> D, since they require a config option to be set before their use is
>>> safe.
>>
>> Funnily enough, this comment is immediately contradicted by the vector
>> subset extensions, where these CHECK_ISA_EXT() macros are used wrapped
>> in has_vector(). The code looks valid to me, since has_vector() contains
>> the Kconfig check, but does fly in the face of this comment.
>
>
> Ohh, got it. The word "can" is doing a lot of heavy lifting in that
> comment. So maybe something like: "This macro performs little in the
> way of extension-specific kernel readiness checks. It's assumed other
> gating factors like required Kconfig settings have already been
> confirmed to support exposing the given extension to usermode". ...
> But, you know, make it sparkle.
Hi Even,
Indeed the comment was a bit misleading, is this more clear ?
/*
* Only use CHECK_ISA_EXT() for extensions which are usable by
* userspace with respect to the kernel current configuration.
* For instance, ISA extensions that uses float operations
* should not be exposed when CONFIG_FPU is not set.
*/
Clément
>
> -Evan
On Thu, Oct 19, 2023 at 09:26:31AM +0200, Clément Léger wrote:
>
>
> On 18/10/2023 19:36, Conor Dooley wrote:
> > On Wed, Oct 18, 2023 at 06:33:34PM +0100, Conor Dooley wrote:
> >> On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
> >>> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
> >>>>
> >>>> Factorize ISA extension reporting by using a macro rather than
> >>>> copy/pasting extension names. This will allow adding new extensions more
> >>>> easily.
> >>>>
> >>>> Signed-off-by: Clément Léger <[email protected]>
> >>>> ---
> >>>> arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
> >>>> 1 file changed, 18 insertions(+), 14 deletions(-)
> >>>>
> >>>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
> >>>> index 473159b5f303..e207874e686e 100644
> >>>> --- a/arch/riscv/kernel/sys_riscv.c
> >>>> +++ b/arch/riscv/kernel/sys_riscv.c
> >>>> @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
> >>>> for_each_cpu(cpu, cpus) {
> >>>> struct riscv_isainfo *isainfo = &hart_isa[cpu];
> >>>>
> >>>> - if (riscv_isa_extension_available(isainfo->isa, ZBA))
> >>>> - pair->value |= RISCV_HWPROBE_EXT_ZBA;
> >>>> - else
> >>>> - missing |= RISCV_HWPROBE_EXT_ZBA;
> >>>> -
> >>>> - if (riscv_isa_extension_available(isainfo->isa, ZBB))
> >>>> - pair->value |= RISCV_HWPROBE_EXT_ZBB;
> >>>> - else
> >>>> - missing |= RISCV_HWPROBE_EXT_ZBB;
> >>>> -
> >>>> - if (riscv_isa_extension_available(isainfo->isa, ZBS))
> >>>> - pair->value |= RISCV_HWPROBE_EXT_ZBS;
> >>>> - else
> >>>> - missing |= RISCV_HWPROBE_EXT_ZBS;
> >>>> +#define CHECK_ISA_EXT(__ext) \
> >>>> + do { \
> >>>> + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
> >>>> + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
> >>>> + else \
> >>>> + missing |= RISCV_HWPROBE_EXT_##__ext; \
> >>>> + } while (false)
> >>>> +
> >>>> + /*
> >>>> + * Only use CHECK_ISA_EXT() for extensions which can be exposed
> >>>> + * to userspace, regardless of the kernel's configuration, as no
> >>>> + * other checks, besides presence in the hart_isa bitmap, are
> >>>> + * made.
> >>>
> >>> This comment alludes to a dangerous trap, but I'm having trouble
> >>> understanding what it is.
> >>
> >> You cannot, for example, use this for communicating the presence of F or
> >> D, since they require a config option to be set before their use is
> >> safe.
> >
> > Funnily enough, this comment is immediately contradicted by the vector
> > subset extensions, where these CHECK_ISA_EXT() macros are used wrapped
> > in has_vector(). The code looks valid to me, since has_vector() contains
> > the Kconfig check, but does fly in the face of this comment.
> Yes, the KConfig checks are already done by the headers, adding #ifdef
> would be redundant even if more coherent with the comment
I don't really understand what the first part of this means, or why using
avoidable ifdeffery here would be desirable.
> BTW, wouldn't
> it make more sense to get rid out of the unsupported extensions directly
> at ISA string parsing ? ie, if kernel is compiled without V support,
> then do not set the bits corresponding to these in the riscv_isa_ext[]
> array ? But the initial intent was probably to be able to report the
> full string through cpuinfo.
Yeah, hysterical raisins I guess, it's always been that way. I don't
think anyone originally thought about such configurations and that is
how the cpuinfo stuff behaves. I strongly dislike the
riscv_isa_extension_available() interface, but one of Drew's patches
does at least improve things a bit. Kinda waiting for some of the
patches in flight to settle down before deciding if I want to refactor
stuff to be less of a potential for shooting oneself in the foot.
On Thu, Oct 19, 2023 at 11:46:51AM +0200, Cl?ment L?ger wrote:
> Indeed the comment was a bit misleading, is this more clear ?
>
> /*
> * Only use CHECK_ISA_EXT() for extensions which are usable by
> * userspace with respect to the kernel current configuration.
> * For instance, ISA extensions that uses float operations
s/that uses/that use/
> * should not be exposed when CONFIG_FPU is not set.
s/is not set/is not enabled/
But yeah, definitely more clear, thanks.
On 19/10/2023 12:22, Conor Dooley wrote:
> On Thu, Oct 19, 2023 at 09:26:31AM +0200, Clément Léger wrote:
>>
>>
>> On 18/10/2023 19:36, Conor Dooley wrote:
>>> On Wed, Oct 18, 2023 at 06:33:34PM +0100, Conor Dooley wrote:
>>>> On Wed, Oct 18, 2023 at 10:24:15AM -0700, Evan Green wrote:
>>>>> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>>>>>
>>>>>> Factorize ISA extension reporting by using a macro rather than
>>>>>> copy/pasting extension names. This will allow adding new extensions more
>>>>>> easily.
>>>>>>
>>>>>> Signed-off-by: Clément Léger <[email protected]>
>>>>>> ---
>>>>>> arch/riscv/kernel/sys_riscv.c | 32 ++++++++++++++++++--------------
>>>>>> 1 file changed, 18 insertions(+), 14 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
>>>>>> index 473159b5f303..e207874e686e 100644
>>>>>> --- a/arch/riscv/kernel/sys_riscv.c
>>>>>> +++ b/arch/riscv/kernel/sys_riscv.c
>>>>>> @@ -145,20 +145,24 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>>>>>> for_each_cpu(cpu, cpus) {
>>>>>> struct riscv_isainfo *isainfo = &hart_isa[cpu];
>>>>>>
>>>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBA))
>>>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBA;
>>>>>> - else
>>>>>> - missing |= RISCV_HWPROBE_EXT_ZBA;
>>>>>> -
>>>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBB))
>>>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBB;
>>>>>> - else
>>>>>> - missing |= RISCV_HWPROBE_EXT_ZBB;
>>>>>> -
>>>>>> - if (riscv_isa_extension_available(isainfo->isa, ZBS))
>>>>>> - pair->value |= RISCV_HWPROBE_EXT_ZBS;
>>>>>> - else
>>>>>> - missing |= RISCV_HWPROBE_EXT_ZBS;
>>>>>> +#define CHECK_ISA_EXT(__ext) \
>>>>>> + do { \
>>>>>> + if (riscv_isa_extension_available(isainfo->isa, __ext)) \
>>>>>> + pair->value |= RISCV_HWPROBE_EXT_##__ext; \
>>>>>> + else \
>>>>>> + missing |= RISCV_HWPROBE_EXT_##__ext; \
>>>>>> + } while (false)
>>>>>> +
>>>>>> + /*
>>>>>> + * Only use CHECK_ISA_EXT() for extensions which can be exposed
>>>>>> + * to userspace, regardless of the kernel's configuration, as no
>>>>>> + * other checks, besides presence in the hart_isa bitmap, are
>>>>>> + * made.
>>>>>
>>>>> This comment alludes to a dangerous trap, but I'm having trouble
>>>>> understanding what it is.
>>>>
>>>> You cannot, for example, use this for communicating the presence of F or
>>>> D, since they require a config option to be set before their use is
>>>> safe.
>>>
>>> Funnily enough, this comment is immediately contradicted by the vector
>>> subset extensions, where these CHECK_ISA_EXT() macros are used wrapped
>>> in has_vector(). The code looks valid to me, since has_vector() contains
>>> the Kconfig check, but does fly in the face of this comment.
>
>> Yes, the KConfig checks are already done by the headers, adding #ifdef
>> would be redundant even if more coherent with the comment
>
> I don't really understand what the first part of this means, or why using
> avoidable ifdeffery here would be desirable.
Sorry, I was not clear enough. What I meant is that the has_fpu() and
has_vector() functions are already ifdef'd in headers based on the
KConfig options for their support (CONFIG_FPU/CONFIG_RISCV_ISA_V) So in
the end, using ifdef here in hwprobe_isa_ext0() would be redundant.
>
>> BTW, wouldn't
>> it make more sense to get rid out of the unsupported extensions directly
>> at ISA string parsing ? ie, if kernel is compiled without V support,
>> then do not set the bits corresponding to these in the riscv_isa_ext[]
>> array ? But the initial intent was probably to be able to report the
>> full string through cpuinfo.
>
> Yeah, hysterical raisins I guess, it's always been that way. I don't
> think anyone originally thought about such configurations and that is
> how the cpuinfo stuff behaves. I strongly dislike the
> riscv_isa_extension_available() interface, but one of Drew's patches
> does at least improve things a bit. Kinda waiting for some of the
> patches in flight to settle down before deciding if I want to refactor
> stuff to be less of a potential for shooting oneself in the foot.
Make sense.
Clément
On Thu, Oct 19, 2023 at 11:35:59AM +0200, Clément Léger wrote:
>
>
> On 18/10/2023 19:26, Evan Green wrote:
> > On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
> >>
> >>
> >>
> >> On 18/10/2023 03:45, Jerry Shih wrote:
> >>> On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
> >>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> >>>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
> >>>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> >>>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> >>>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> >>>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
> >>>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
> >>>
> >>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
> >>
> >> Hi Jerry,
> >>
> >> Thanks for catching this, I think some other extensions will fall in
> >> this category as well then (Zvknha/Zvknhb). I will verify that.
> >
> > The bundling mechanism works well when an extension is a pure lasso
> > around other extensions. We'd have to tweak that code if we wanted to
> > support cases like this, where the extension is a superset of others,
> > but also contains loose change not present anywhere else (and
> > therefore also needs to stand as a separate bit).
>
> For Zvbb and Zvknhb, I used the following code:
>
> static const unsigned int riscv_zvbb_bundled_exts[] = {
> RISCV_ISA_EXT_ZVKB,
> RISCV_ISA_EXT_ZVBB
> };
>
> static const unsigned int riscv_zvknhb_bundled_exts[] = {
> RISCV_ISA_EXT_ZVKNHA,
> RISCV_ISA_EXT_ZVKNHB
> };
>
> Which correctly results in both extension (superset + base set) being
> enabled when only one is set. Is there something that I'm missing ?
>
> >
> > IMO, decomposing "pure" bundles makes sense since otherwise usermode
> > would have to query multiple distinct bitmaps that meant the same
> > thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
> > maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
> > when an extension is a superset that also contains loose change, there
> > really aren't two equivalent bitmasks, each bit adds something new.
>
> Agreed but if a system only report ZVBB for instance and the user wants
> ZVKB, then it is clear that ZVKB should be reported as well I guess. So
> in the end, it works much like "bundle" extension, just that the bundle
> is actually a "real" ISA extension by itself.
>
> Clément
>
> >
> > There's an argument to be made for still turning on the containing
> > extensions to cover for silly ISA strings (eg ISA strings that
> > advertise the superset but fail to advertise the containing
> > extensions). We can decide if we want to work that hard to cover
> > hypothetical broken ISA strings now, or wait until they show up.
> > Personally I would wait until something broken shows up. But others
> > may feel differently.
I'm not really sure that those are "silly" ISA strings. People are going
to do it that way because it is much easier than spelling out 5 dozen
sub-components, and it is pretty inevitable that subsets will be
introduced in the future for extensions we currently have.
IMO, it's perfectly valid to say you have the supersets and not spell
out all the subcomponents.
On Thu, Oct 19, 2023 at 3:24 AM Conor Dooley <[email protected]> wrote:
>
> On Thu, Oct 19, 2023 at 11:46:51AM +0200, Clément Léger wrote:
> > Indeed the comment was a bit misleading, is this more clear ?
> >
> > /*
> > * Only use CHECK_ISA_EXT() for extensions which are usable by
> > * userspace with respect to the kernel current configuration.
> > * For instance, ISA extensions that uses float operations
>
> s/that uses/that use/
>
> > * should not be exposed when CONFIG_FPU is not set.
>
> s/is not set/is not enabled/
>
> But yeah, definitely more clear, thanks.
Looks good to me too. Thanks, Clément!
-Evan
On Thu, Oct 19, 2023 at 8:33 AM Conor Dooley <[email protected]> wrote:
>
> On Thu, Oct 19, 2023 at 11:35:59AM +0200, Clément Léger wrote:
> >
> >
> > On 18/10/2023 19:26, Evan Green wrote:
> > > On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
> > >>
> > >>
> > >>
> > >> On 18/10/2023 03:45, Jerry Shih wrote:
> > >>> On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
> > >>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> > >>>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
> > >>>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> > >>>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> > >>>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> > >>>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
> > >>>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
> > >>>
> > >>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
> > >>
> > >> Hi Jerry,
> > >>
> > >> Thanks for catching this, I think some other extensions will fall in
> > >> this category as well then (Zvknha/Zvknhb). I will verify that.
> > >
> > > The bundling mechanism works well when an extension is a pure lasso
> > > around other extensions. We'd have to tweak that code if we wanted to
> > > support cases like this, where the extension is a superset of others,
> > > but also contains loose change not present anywhere else (and
> > > therefore also needs to stand as a separate bit).
> >
> > For Zvbb and Zvknhb, I used the following code:
> >
> > static const unsigned int riscv_zvbb_bundled_exts[] = {
> > RISCV_ISA_EXT_ZVKB,
> > RISCV_ISA_EXT_ZVBB
> > };
> >
> > static const unsigned int riscv_zvknhb_bundled_exts[] = {
> > RISCV_ISA_EXT_ZVKNHA,
> > RISCV_ISA_EXT_ZVKNHB
> > };
> >
> > Which correctly results in both extension (superset + base set) being
> > enabled when only one is set. Is there something that I'm missing ?
> >
> > >
> > > IMO, decomposing "pure" bundles makes sense since otherwise usermode
> > > would have to query multiple distinct bitmaps that meant the same
> > > thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
> > > maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
> > > when an extension is a superset that also contains loose change, there
> > > really aren't two equivalent bitmasks, each bit adds something new.
> >
> > Agreed but if a system only report ZVBB for instance and the user wants
> > ZVKB, then it is clear that ZVKB should be reported as well I guess. So
> > in the end, it works much like "bundle" extension, just that the bundle
> > is actually a "real" ISA extension by itself.
> >
> > Clément
> >
> > >
> > > There's an argument to be made for still turning on the containing
> > > extensions to cover for silly ISA strings (eg ISA strings that
> > > advertise the superset but fail to advertise the containing
> > > extensions). We can decide if we want to work that hard to cover
> > > hypothetical broken ISA strings now, or wait until they show up.
> > > Personally I would wait until something broken shows up. But others
> > > may feel differently.
>
> I'm not really sure that those are "silly" ISA strings. People are going
> to do it that way because it is much easier than spelling out 5 dozen
> sub-components, and it is pretty inevitable that subsets will be
> introduced in the future for extensions we currently have.
>
> IMO, it's perfectly valid to say you have the supersets and not spell
> out all the subcomponents.
Hm, ok. If ISA strings are likely to be written that way, then I agree
having the kernel flip on all the contained extensions is a good idea.
We can tweak patch 2 to support the parsing of struct
riscv_isa_ext_data with both .id and .bundle_size set (instead of only
one or the other as it is now). Looking back at that patch, it looks
quite doable. Alright!
-Evan
On Oct 19, 2023, at 17:35, Clément Léger <[email protected]> wrote:
> On 18/10/2023 19:26, Evan Green wrote:
>> On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
>>>
>>> On 18/10/2023 03:45, Jerry Shih wrote:
>>>>
>>>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
>>>
>>> Hi Jerry,
>>>
>>> Thanks for catching this, I think some other extensions will fall in
>>> this category as well then (Zvknha/Zvknhb). I will verify that.
>>
>> The bundling mechanism works well when an extension is a pure lasso
>> around other extensions. We'd have to tweak that code if we wanted to
>> support cases like this, where the extension is a superset of others,
>> but also contains loose change not present anywhere else (and
>> therefore also needs to stand as a separate bit).
>
> For Zvbb and Zvknhb, I used the following code:
>
> static const unsigned int riscv_zvbb_bundled_exts[] = {
> RISCV_ISA_EXT_ZVKB,
> RISCV_ISA_EXT_ZVBB
> };
>
> static const unsigned int riscv_zvknhb_bundled_exts[] = {
> RISCV_ISA_EXT_ZVKNHA,
> RISCV_ISA_EXT_ZVKNHB
> };
>
> Which correctly results in both extension (superset + base set) being
> enabled when only one is set. Is there something that I'm missing ?
We should not bundle zvknha and zvknhb together. They are exclusive.
Please check:
https://github.com/riscv/riscv-crypto/issues/364#issuecomment-1726782096
-Jerry
On Thu, Oct 19, 2023 at 11:22:26AM +0100, Conor Dooley wrote:
> On Thu, Oct 19, 2023 at 09:26:31AM +0200, Cl?ment L?ger wrote:
...
> > BTW, wouldn't
> > it make more sense to get rid out of the unsupported extensions directly
> > at ISA string parsing ? ie, if kernel is compiled without V support,
> > then do not set the bits corresponding to these in the riscv_isa_ext[]
> > array ? But the initial intent was probably to be able to report the
> > full string through cpuinfo.
>
> Yeah, hysterical raisins I guess, it's always been that way. I don't
> think anyone originally thought about such configurations and that is
> how the cpuinfo stuff behaves. I strongly dislike the
> riscv_isa_extension_available() interface, but one of Drew's patches
> does at least improve things a bit. Kinda waiting for some of the
> patches in flight to settle down before deciding if I want to refactor
> stuff to be less of a potential for shooting oneself in the foot.
And I recall promising to try and do something with it too, but that
promise got buried under other promises... It's still on the TODO, at
least!
drew
On 20/10/2023 04:43, Jerry Shih wrote:
> On Oct 19, 2023, at 17:35, Clément Léger <[email protected]> wrote:
>> On 18/10/2023 19:26, Evan Green wrote:
>>> On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
>>>>
>>>> On 18/10/2023 03:45, Jerry Shih wrote:
>>>>>
>>>>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
>>>>
>>>> Hi Jerry,
>>>>
>>>> Thanks for catching this, I think some other extensions will fall in
>>>> this category as well then (Zvknha/Zvknhb). I will verify that.
>>>
>>> The bundling mechanism works well when an extension is a pure lasso
>>> around other extensions. We'd have to tweak that code if we wanted to
>>> support cases like this, where the extension is a superset of others,
>>> but also contains loose change not present anywhere else (and
>>> therefore also needs to stand as a separate bit).
>>
>> For Zvbb and Zvknhb, I used the following code:
>>
>> static const unsigned int riscv_zvbb_bundled_exts[] = {
>> RISCV_ISA_EXT_ZVKB,
>> RISCV_ISA_EXT_ZVBB
>> };
>>
>> static const unsigned int riscv_zvknhb_bundled_exts[] = {
>> RISCV_ISA_EXT_ZVKNHA,
>> RISCV_ISA_EXT_ZVKNHB
>> };
>>
>> Which correctly results in both extension (superset + base set) being
>> enabled when only one is set. Is there something that I'm missing ?
>
> We should not bundle zvknha and zvknhb together. They are exclusive.
Yes, but for instance, what happens if the user query the zvknha (if it
only needs SHA256) but zvknhb is present. If we don't declare zvknha,
then it will fail but the support would actually be present due to
zvknhb being there.
Clément
> Please check:
> https://github.com/riscv/riscv-crypto/issues/364#issuecomment-1726782096
>
> -Jerry
>
On 19/10/2023 18:19, Evan Green wrote:
> On Thu, Oct 19, 2023 at 8:33 AM Conor Dooley <[email protected]> wrote:
>>
>> On Thu, Oct 19, 2023 at 11:35:59AM +0200, Clément Léger wrote:
>>>
>>>
>>> On 18/10/2023 19:26, Evan Green wrote:
>>>> On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 18/10/2023 03:45, Jerry Shih wrote:
>>>>>> On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
>>>>>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>>>>>>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
>>>>>>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
>>>>>>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
>>>>>>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
>>>>>>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
>>>>>>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
>>>>>>
>>>>>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
>>>>>
>>>>> Hi Jerry,
>>>>>
>>>>> Thanks for catching this, I think some other extensions will fall in
>>>>> this category as well then (Zvknha/Zvknhb). I will verify that.
>>>>
>>>> The bundling mechanism works well when an extension is a pure lasso
>>>> around other extensions. We'd have to tweak that code if we wanted to
>>>> support cases like this, where the extension is a superset of others,
>>>> but also contains loose change not present anywhere else (and
>>>> therefore also needs to stand as a separate bit).
>>>
>>> For Zvbb and Zvknhb, I used the following code:
>>>
>>> static const unsigned int riscv_zvbb_bundled_exts[] = {
>>> RISCV_ISA_EXT_ZVKB,
>>> RISCV_ISA_EXT_ZVBB
>>> };
>>>
>>> static const unsigned int riscv_zvknhb_bundled_exts[] = {
>>> RISCV_ISA_EXT_ZVKNHA,
>>> RISCV_ISA_EXT_ZVKNHB
>>> };
>>>
>>> Which correctly results in both extension (superset + base set) being
>>> enabled when only one is set. Is there something that I'm missing ?
>>>
>>>>
>>>> IMO, decomposing "pure" bundles makes sense since otherwise usermode
>>>> would have to query multiple distinct bitmaps that meant the same
>>>> thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
>>>> maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
>>>> when an extension is a superset that also contains loose change, there
>>>> really aren't two equivalent bitmasks, each bit adds something new.
>>>
>>> Agreed but if a system only report ZVBB for instance and the user wants
>>> ZVKB, then it is clear that ZVKB should be reported as well I guess. So
>>> in the end, it works much like "bundle" extension, just that the bundle
>>> is actually a "real" ISA extension by itself.
>>>
>>> Clément
>>>
>>>>
>>>> There's an argument to be made for still turning on the containing
>>>> extensions to cover for silly ISA strings (eg ISA strings that
>>>> advertise the superset but fail to advertise the containing
>>>> extensions). We can decide if we want to work that hard to cover
>>>> hypothetical broken ISA strings now, or wait until they show up.
>>>> Personally I would wait until something broken shows up. But others
>>>> may feel differently.
>>
>> I'm not really sure that those are "silly" ISA strings. People are going
>> to do it that way because it is much easier than spelling out 5 dozen
>> sub-components, and it is pretty inevitable that subsets will be
>> introduced in the future for extensions we currently have.
>>
>> IMO, it's perfectly valid to say you have the supersets and not spell
>> out all the subcomponents.
>
> Hm, ok. If ISA strings are likely to be written that way, then I agree
> having the kernel flip on all the contained extensions is a good idea.
> We can tweak patch 2 to support the parsing of struct
> riscv_isa_ext_data with both .id and .bundle_size set (instead of only
> one or the other as it is now). Looking back at that patch, it looks
> quite doable. Alright!
Hey Evan,
do you have anything against using this code:
static const unsigned int riscv_zvbb_bundled_exts[] = {
RISCV_ISA_EXT_ZVKB,
RISCV_ISA_EXT_ZVBB
};
...
Then declaring zvbb like that:
__RISCV_ISA_EXT_BUNDLE(zvbb, riscv_zvbb_bundled_exts),
I agree that it is *not* a bundled extension but it actually already
works with Conor's code. Not sure that adding more code is needed to
handle that case.
Clément
>
> -Evan
On Mon, Oct 23, 2023 at 12:24 AM Clément Léger <[email protected]> wrote:
>
>
>
> On 19/10/2023 18:19, Evan Green wrote:
> > On Thu, Oct 19, 2023 at 8:33 AM Conor Dooley <[email protected]> wrote:
> >>
> >> On Thu, Oct 19, 2023 at 11:35:59AM +0200, Clément Léger wrote:
> >>>
> >>>
> >>> On 18/10/2023 19:26, Evan Green wrote:
> >>>> On Wed, Oct 18, 2023 at 5:53 AM Clément Léger <[email protected]> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18/10/2023 03:45, Jerry Shih wrote:
> >>>>>> On Oct 17, 2023, at 21:14, Clément Léger <[email protected]> wrote:
> >>>>>>> @@ -221,6 +261,22 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> >>>>>>> __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT),
> >>>>>>> __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED),
> >>>>>>> __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH),
> >>>>>>> + __RISCV_ISA_EXT_DATA(zvbb, RISCV_ISA_EXT_ZVBB),
> >>>>>>> + __RISCV_ISA_EXT_DATA(zvbc, RISCV_ISA_EXT_ZVBC),
> >>>>>>> + __RISCV_ISA_EXT_DATA(zvkb, RISCV_ISA_EXT_ZVKB),
> >>>>>>
> >>>>>> The `Zvkb` is the subset of `Zvbb`[1]. So, the `Zvkb` should be bundled with `Zvbb`.
> >>>>>
> >>>>> Hi Jerry,
> >>>>>
> >>>>> Thanks for catching this, I think some other extensions will fall in
> >>>>> this category as well then (Zvknha/Zvknhb). I will verify that.
> >>>>
> >>>> The bundling mechanism works well when an extension is a pure lasso
> >>>> around other extensions. We'd have to tweak that code if we wanted to
> >>>> support cases like this, where the extension is a superset of others,
> >>>> but also contains loose change not present anywhere else (and
> >>>> therefore also needs to stand as a separate bit).
> >>>
> >>> For Zvbb and Zvknhb, I used the following code:
> >>>
> >>> static const unsigned int riscv_zvbb_bundled_exts[] = {
> >>> RISCV_ISA_EXT_ZVKB,
> >>> RISCV_ISA_EXT_ZVBB
> >>> };
> >>>
> >>> static const unsigned int riscv_zvknhb_bundled_exts[] = {
> >>> RISCV_ISA_EXT_ZVKNHA,
> >>> RISCV_ISA_EXT_ZVKNHB
> >>> };
> >>>
> >>> Which correctly results in both extension (superset + base set) being
> >>> enabled when only one is set. Is there something that I'm missing ?
> >>>
> >>>>
> >>>> IMO, decomposing "pure" bundles makes sense since otherwise usermode
> >>>> would have to query multiple distinct bitmaps that meant the same
> >>>> thing (eg check the Zk bit, or maybe check the Zkn/Zkr/Zkt bits, or
> >>>> maybe check the Zbkb/Zbkc... bits, and they're all equivalent). But
> >>>> when an extension is a superset that also contains loose change, there
> >>>> really aren't two equivalent bitmasks, each bit adds something new.
> >>>
> >>> Agreed but if a system only report ZVBB for instance and the user wants
> >>> ZVKB, then it is clear that ZVKB should be reported as well I guess. So
> >>> in the end, it works much like "bundle" extension, just that the bundle
> >>> is actually a "real" ISA extension by itself.
> >>>
> >>> Clément
> >>>
> >>>>
> >>>> There's an argument to be made for still turning on the containing
> >>>> extensions to cover for silly ISA strings (eg ISA strings that
> >>>> advertise the superset but fail to advertise the containing
> >>>> extensions). We can decide if we want to work that hard to cover
> >>>> hypothetical broken ISA strings now, or wait until they show up.
> >>>> Personally I would wait until something broken shows up. But others
> >>>> may feel differently.
> >>
> >> I'm not really sure that those are "silly" ISA strings. People are going
> >> to do it that way because it is much easier than spelling out 5 dozen
> >> sub-components, and it is pretty inevitable that subsets will be
> >> introduced in the future for extensions we currently have.
> >>
> >> IMO, it's perfectly valid to say you have the supersets and not spell
> >> out all the subcomponents.
> >
> > Hm, ok. If ISA strings are likely to be written that way, then I agree
> > having the kernel flip on all the contained extensions is a good idea.
> > We can tweak patch 2 to support the parsing of struct
> > riscv_isa_ext_data with both .id and .bundle_size set (instead of only
> > one or the other as it is now). Looking back at that patch, it looks
> > quite doable. Alright!
>
> Hey Evan,
>
> do you have anything against using this code:
>
> static const unsigned int riscv_zvbb_bundled_exts[] = {
> RISCV_ISA_EXT_ZVKB,
> RISCV_ISA_EXT_ZVBB
> };
>
> ...
>
> Then declaring zvbb like that:
>
> __RISCV_ISA_EXT_BUNDLE(zvbb, riscv_zvbb_bundled_exts),
>
> I agree that it is *not* a bundled extension but it actually already
> works with Conor's code. Not sure that adding more code is needed to
> handle that case.
Ah, I had missed that Zvbb was in Zvbb's own bundle. I see now that it
works, but it also feels a bit like we're working around our own code.
An alternate way, which you can decide if you like better, would be a
new macro (something like __RISCV_ISA_EXT_DATA_BUNDLE(), but better
names welcome) that allows setting both .id and .bundle_size. Then the
else-if in match_isa_ext() could just turn into two independent ifs.
You'd have to define an "invalid" value for .id, since 0 is 'a', but
that should be straightforward. Or maybe jiggle things around a bit so
0 is invalid and 'a' is 1.
-Evan
On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>
> From: Evan Green <[email protected]>
>
> The Scalar Crypto specification defines Zk as a shorthand for the
> Zkn, Zkr and Zkt extensions. The same follows for both Zkn, Zks and Zbk,
> which are all shorthands for various other extensions. The detailed
> breakdown can be found in their dt-binding entries.
>
> Since Zkn also implies the Zbkb, Zbkc and Zbkx extensions, simply passing
> "zk" through a DT should enable all of Zbkb, Zbkc, Zbkx, Zkn, Zkr and Zkt.
> For example, setting the "riscv,isa" DT property to "rv64imafdc_zk"
> should generate the following cpuinfo output:
> "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zkt"
>
> riscv_isa_ext_data grows a pair of new members, to permit setting the
> relevant bits for "bundled" extensions, both while parsing the ISA string
> and the new dedicated extension properties
>
> Co-developed-by: Conor Dooley <[email protected]>
> Signed-off-by: Conor Dooley <[email protected]>
> Signed-off-by: Evan Green <[email protected]>
> Signed-off-by: Clément Léger <[email protected]>
My tree might be out of sync, but in my search for riscv_isa_ext, I
also found a use in print_isa() (cpu.c) where we're reaching into
riscv_isa_ext[].id and assuming it's always valid. If that's still in
there we'll want to fix up that spot too, since now with bundles .id
may or may not be valid.
-Evan
On 23/10/2023 18:21, Evan Green wrote:
> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>
>> From: Evan Green <[email protected]>
>>
>> The Scalar Crypto specification defines Zk as a shorthand for the
>> Zkn, Zkr and Zkt extensions. The same follows for both Zkn, Zks and Zbk,
>> which are all shorthands for various other extensions. The detailed
>> breakdown can be found in their dt-binding entries.
>>
>> Since Zkn also implies the Zbkb, Zbkc and Zbkx extensions, simply passing
>> "zk" through a DT should enable all of Zbkb, Zbkc, Zbkx, Zkn, Zkr and Zkt.
>> For example, setting the "riscv,isa" DT property to "rv64imafdc_zk"
>> should generate the following cpuinfo output:
>> "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zkt"
>>
>> riscv_isa_ext_data grows a pair of new members, to permit setting the
>> relevant bits for "bundled" extensions, both while parsing the ISA string
>> and the new dedicated extension properties
>>
>> Co-developed-by: Conor Dooley <[email protected]>
>> Signed-off-by: Conor Dooley <[email protected]>
>> Signed-off-by: Evan Green <[email protected]>
>> Signed-off-by: Clément Léger <[email protected]>
>
> My tree might be out of sync, but in my search for riscv_isa_ext, I
> also found a use in print_isa() (cpu.c) where we're reaching into
> riscv_isa_ext[].id and assuming it's always valid. If that's still in
> there we'll want to fix up that spot too, since now with bundles .id
> may or may not be valid.
Oh indeed, the array is visible outside of this compilation unit :/.
I'll check that before sending V3.
Clément
>
> -Evan
On 24/10/2023 09:18, Clément Léger wrote:
>
>
> On 23/10/2023 18:21, Evan Green wrote:
>> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>>
>>> From: Evan Green <[email protected]>
>>>
>>> The Scalar Crypto specification defines Zk as a shorthand for the
>>> Zkn, Zkr and Zkt extensions. The same follows for both Zkn, Zks and Zbk,
>>> which are all shorthands for various other extensions. The detailed
>>> breakdown can be found in their dt-binding entries.
>>>
>>> Since Zkn also implies the Zbkb, Zbkc and Zbkx extensions, simply passing
>>> "zk" through a DT should enable all of Zbkb, Zbkc, Zbkx, Zkn, Zkr and Zkt.
>>> For example, setting the "riscv,isa" DT property to "rv64imafdc_zk"
>>> should generate the following cpuinfo output:
>>> "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zkt"
>>>
>>> riscv_isa_ext_data grows a pair of new members, to permit setting the
>>> relevant bits for "bundled" extensions, both while parsing the ISA string
>>> and the new dedicated extension properties
>>>
>>> Co-developed-by: Conor Dooley <[email protected]>
>>> Signed-off-by: Conor Dooley <[email protected]>
>>> Signed-off-by: Evan Green <[email protected]>
>>> Signed-off-by: Clément Léger <[email protected]>
>>
>> My tree might be out of sync, but in my search for riscv_isa_ext, I
>> also found a use in print_isa() (cpu.c) where we're reaching into
>> riscv_isa_ext[].id and assuming it's always valid. If that's still in
>> there we'll want to fix up that spot too, since now with bundles .id
>> may or may not be valid.
>
> Oh indeed, the array is visible outside of this compilation unit :/.
> I'll check that before sending V3.
After looking a bit more at that, it actually seems that id is used in
cpuinfo to determine which extensions are present which means you are
right, bundle_size needs to be accounted for.
Looking at it also raises the question (again) of exposing the "bundles"
extensions themselves or not in cpuinfo output. With the current setup,
the bundles extensions won't be visible in cpuinfo output. For instance
if Zk was in the isa string, then it will not be visible in the cpuinfo
output, only the child extensions. One solution would be to always have
a valid id for each extension. So we would have one for Zk for instance.
We would then have a similar setup for all "bundles" or "subset"
extensions, they would have a id for all of them. For instance, Zk would
become:
__RISCV_ISA_EXT_DATA_BUNDLE(zk, RISCV_ISA_EXT_ZK, riscv_zk_bundled_exts)
Same would go for zvbb (riscv_zvbb_subset_exts would only contain Zvkb):
__RISCV_ISA_EXT_DATA_BUNDLE(zk, RISCV_ISA_EXT_ZVBB, riscv_zvbb_subset_exts)
For the sake of completeness, I feel like it would be good to have all
the extensions (bundles or not) visible in the riscv_isa_ext.
Any objection ?
Clément
>
> Clément
>
>>
>> -Evan
On Tue, Oct 24, 2023 at 2:30 AM Clément Léger <[email protected]> wrote:
>
>
>
> On 24/10/2023 09:18, Clément Léger wrote:
> >
> >
> > On 23/10/2023 18:21, Evan Green wrote:
> >> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
> >>>
> >>> From: Evan Green <[email protected]>
> >>>
> >>> The Scalar Crypto specification defines Zk as a shorthand for the
> >>> Zkn, Zkr and Zkt extensions. The same follows for both Zkn, Zks and Zbk,
> >>> which are all shorthands for various other extensions. The detailed
> >>> breakdown can be found in their dt-binding entries.
> >>>
> >>> Since Zkn also implies the Zbkb, Zbkc and Zbkx extensions, simply passing
> >>> "zk" through a DT should enable all of Zbkb, Zbkc, Zbkx, Zkn, Zkr and Zkt.
> >>> For example, setting the "riscv,isa" DT property to "rv64imafdc_zk"
> >>> should generate the following cpuinfo output:
> >>> "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zkt"
> >>>
> >>> riscv_isa_ext_data grows a pair of new members, to permit setting the
> >>> relevant bits for "bundled" extensions, both while parsing the ISA string
> >>> and the new dedicated extension properties
> >>>
> >>> Co-developed-by: Conor Dooley <[email protected]>
> >>> Signed-off-by: Conor Dooley <[email protected]>
> >>> Signed-off-by: Evan Green <[email protected]>
> >>> Signed-off-by: Clément Léger <[email protected]>
> >>
> >> My tree might be out of sync, but in my search for riscv_isa_ext, I
> >> also found a use in print_isa() (cpu.c) where we're reaching into
> >> riscv_isa_ext[].id and assuming it's always valid. If that's still in
> >> there we'll want to fix up that spot too, since now with bundles .id
> >> may or may not be valid.
> >
> > Oh indeed, the array is visible outside of this compilation unit :/.
> > I'll check that before sending V3.
>
> After looking a bit more at that, it actually seems that id is used in
> cpuinfo to determine which extensions are present which means you are
> right, bundle_size needs to be accounted for.
>
> Looking at it also raises the question (again) of exposing the "bundles"
> extensions themselves or not in cpuinfo output. With the current setup,
> the bundles extensions won't be visible in cpuinfo output. For instance
> if Zk was in the isa string, then it will not be visible in the cpuinfo
> output, only the child extensions. One solution would be to always have
> a valid id for each extension. So we would have one for Zk for instance.
>
> We would then have a similar setup for all "bundles" or "subset"
> extensions, they would have a id for all of them. For instance, Zk would
> become:
>
> __RISCV_ISA_EXT_DATA_BUNDLE(zk, RISCV_ISA_EXT_ZK, riscv_zk_bundled_exts)
>
> Same would go for zvbb (riscv_zvbb_subset_exts would only contain Zvkb):
>
> __RISCV_ISA_EXT_DATA_BUNDLE(zk, RISCV_ISA_EXT_ZVBB, riscv_zvbb_subset_exts)
>
> For the sake of completeness, I feel like it would be good to have all
> the extensions (bundles or not) visible in the riscv_isa_ext.
>
> Any objection ?
I could be persuaded that it's a good idea, but there are arguments to
be made for not defining them as separate bits:
1. Having two (sets of) bits that mean the same thing means usermode
now has to decide which one to query, or query both. Multiple values
that mean the same thing is always something that makes me nervous.
2. To avoid these two sets having different answers, we'd have to
solve the reverse problem too: If all of the bundled extensions that
make up Zk are on, we'd need to detect that and turn Zk on as well.
That code would also need to know the difference between a pure lasso
like Zk, where you should flip it on if its components are on, and the
loose change variant we were discussing on the other thread (Zvkb?),
where you cannot.
Pretending pure lasso extensions didn't exist on their own was a way
to sidestep the problem.
-Evan
On 24/10/2023 18:37, Evan Green wrote:
> On Tue, Oct 24, 2023 at 2:30 AM Clément Léger <[email protected]> wrote:
>>
>>
>>
>> On 24/10/2023 09:18, Clément Léger wrote:
>>>
>>>
>>> On 23/10/2023 18:21, Evan Green wrote:
>>>> On Tue, Oct 17, 2023 at 6:15 AM Clément Léger <[email protected]> wrote:
>>>>>
>>>>> From: Evan Green <[email protected]>
>>>>>
>>>>> The Scalar Crypto specification defines Zk as a shorthand for the
>>>>> Zkn, Zkr and Zkt extensions. The same follows for both Zkn, Zks and Zbk,
>>>>> which are all shorthands for various other extensions. The detailed
>>>>> breakdown can be found in their dt-binding entries.
>>>>>
>>>>> Since Zkn also implies the Zbkb, Zbkc and Zbkx extensions, simply passing
>>>>> "zk" through a DT should enable all of Zbkb, Zbkc, Zbkx, Zkn, Zkr and Zkt.
>>>>> For example, setting the "riscv,isa" DT property to "rv64imafdc_zk"
>>>>> should generate the following cpuinfo output:
>>>>> "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zkt"
>>>>>
>>>>> riscv_isa_ext_data grows a pair of new members, to permit setting the
>>>>> relevant bits for "bundled" extensions, both while parsing the ISA string
>>>>> and the new dedicated extension properties
>>>>>
>>>>> Co-developed-by: Conor Dooley <[email protected]>
>>>>> Signed-off-by: Conor Dooley <[email protected]>
>>>>> Signed-off-by: Evan Green <[email protected]>
>>>>> Signed-off-by: Clément Léger <[email protected]>
>>>>
>>>> My tree might be out of sync, but in my search for riscv_isa_ext, I
>>>> also found a use in print_isa() (cpu.c) where we're reaching into
>>>> riscv_isa_ext[].id and assuming it's always valid. If that's still in
>>>> there we'll want to fix up that spot too, since now with bundles .id
>>>> may or may not be valid.
>>>
>>> Oh indeed, the array is visible outside of this compilation unit :/.
>>> I'll check that before sending V3.
>>
>> After looking a bit more at that, it actually seems that id is used in
>> cpuinfo to determine which extensions are present which means you are
>> right, bundle_size needs to be accounted for.
>>
>> Looking at it also raises the question (again) of exposing the "bundles"
>> extensions themselves or not in cpuinfo output. With the current setup,
>> the bundles extensions won't be visible in cpuinfo output. For instance
>> if Zk was in the isa string, then it will not be visible in the cpuinfo
>> output, only the child extensions. One solution would be to always have
>> a valid id for each extension. So we would have one for Zk for instance.
>>
>> We would then have a similar setup for all "bundles" or "subset"
>> extensions, they would have a id for all of them. For instance, Zk would
>> become:
>>
>> __RISCV_ISA_EXT_DATA_BUNDLE(zk, RISCV_ISA_EXT_ZK, riscv_zk_bundled_exts)
>>
>> Same would go for zvbb (riscv_zvbb_subset_exts would only contain Zvkb):
>>
>> __RISCV_ISA_EXT_DATA_BUNDLE(zk, RISCV_ISA_EXT_ZVBB, riscv_zvbb_subset_exts)
>>
>> For the sake of completeness, I feel like it would be good to have all
>> the extensions (bundles or not) visible in the riscv_isa_ext.
>>
>> Any objection ?
>
> I could be persuaded that it's a good idea, but there are arguments to
> be made for not defining them as separate bits:
>
> 1. Having two (sets of) bits that mean the same thing means usermode
> now has to decide which one to query, or query both. Multiple values
> that mean the same thing is always something that makes me nervous.
That is indeed an acceptable cons.
> 2. To avoid these two sets having different answers, we'd have to
> solve the reverse problem too: If all of the bundled extensions that
> make up Zk are on, we'd need to detect that and turn Zk on as well.
Oh yes, sorry, already forgot that point :/ Well, I guess things sorted
out by themselves. Let's do what you proposed:
- Pure lasso extensions (Zk) will simply result in all the sub
extensions being enable, there won't be any .id specified for these
ones, simply a bundle of extensions.
- "Superset" extensions (Zvbb for instance) will have their own .id as
well as a bundle made of subsets extensions.
Clément
> That code would also need to know the difference between a pure lasso
> like Zk, where you should flip it on if its components are on, and the
> loose change variant we were discussing on the other thread (Zvkb?),
> where you cannot.
>
> Pretending pure lasso extensions didn't exist on their own was a way
> to sidestep the problem.
> -Evan