[PATCH v5 6/8] riscv: hwprobe: add zve Vector subextensions into hwprobe interface

[Palmer Dabbelt]

On Thu, 09 May 2024 09:26:56 PDT (-0700), andy.chiu at sifive.com wrote:
> The following Vector subextensions for "embedded" platforms are added
> into RISCV_HWPROBE_KEY_IMA_EXT_0:
>  - ZVE32X
>  - ZVE32F
>  - ZVE64X
>  - ZVE64F
>  - ZVE64D
>
> Extensions ending with an X indicates that the platform doesn't have a
> vector FPU.
> Extensions ending with F/D mean that whether single (F) or double (D)
> precision vector operation is supported.
> The number 32 or 64 follows from ZVE tells the maximum element length.
>
> Signed-off-by: Andy Chiu <andy.chiu at sifive.com>
> Reviewed-by: Clément Léger <cleger at rivosinc.com>
> ---
> Changelog v5:
>  - Rebase thus add ZVE32X after RISCV_HWPROBE_EXT_ZICOND.
> Changelog v2:
>  - zve* extensions in hwprobe depends on whether kernel supports v, so
>    include them after has_vector(). Fix a typo. (Clément)
> ---
>  Documentation/arch/riscv/hwprobe.rst  | 15 +++++++++++++++
>  arch/riscv/include/uapi/asm/hwprobe.h |  5 +++++
>  arch/riscv/kernel/sys_hwprobe.c       |  5 +++++
>  3 files changed, 25 insertions(+)
>
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index 204cd4433af5..fc015b452ebf 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -192,6 +192,21 @@ The following keys are defined:
>         supported as defined in the RISC-V ISA manual starting from commit
>         d8ab5c78c207 ("Zihintpause is ratified").
>
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is
> +    supported, as defined by version 1.0 of the RISC-V Vector extension manual.
> +
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZVE32F`: The Vector sub-extension Zve32f is
> +    supported, as defined by version 1.0 of the RISC-V Vector extension manual.
> +
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZVE64X`: The Vector sub-extension Zve64x is
> +    supported, as defined by version 1.0 of the RISC-V Vector extension manual.
> +
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZVE64F`: The Vector sub-extension Zve64f is
> +    supported, as defined by version 1.0 of the RISC-V Vector extension manual.
> +
> +  * :c:macro:`RISCV_HWPROBE_EXT_ZVE64D`: The Vector sub-extension Zve64d is
> +    supported, as defined by version 1.0 of the RISC-V Vector extension manual.
> +
>  * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
>    information about the selected set of processors.
>
> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> index 31c570cbd1c5..6593aedb9d2b 100644
> --- a/arch/riscv/include/uapi/asm/hwprobe.h
> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> @@ -60,6 +60,11 @@ struct riscv_hwprobe {
>  #define		RISCV_HWPROBE_EXT_ZACAS		(1ULL << 34)
>  #define		RISCV_HWPROBE_EXT_ZICOND	(1ULL << 35)
>  #define		RISCV_HWPROBE_EXT_ZIHINTPAUSE	(1ULL << 36)
> +#define		RISCV_HWPROBE_EXT_ZVE32X	(1ULL << 37)
> +#define		RISCV_HWPROBE_EXT_ZVE32F	(1ULL << 38)
> +#define		RISCV_HWPROBE_EXT_ZVE64X	(1ULL << 39)
> +#define		RISCV_HWPROBE_EXT_ZVE64F	(1ULL << 40)
> +#define		RISCV_HWPROBE_EXT_ZVE64D	(1ULL << 41)
>  #define RISCV_HWPROBE_KEY_CPUPERF_0	5
>  #define		RISCV_HWPROBE_MISALIGNED_UNKNOWN	(0 << 0)
>  #define		RISCV_HWPROBE_MISALIGNED_EMULATED	(1 << 0)
> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index 969ef3d59dbe..35390b4a5a17 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c
> @@ -114,6 +114,11 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
>  		EXT_KEY(ZIHINTPAUSE);
>
>  		if (has_vector()) {
> +			EXT_KEY(ZVE32X);
> +			EXT_KEY(ZVE32F);
> +			EXT_KEY(ZVE64X);
> +			EXT_KEY(ZVE64F);
> +			EXT_KEY(ZVE64D);
>  			EXT_KEY(ZVBB);
>  			EXT_KEY(ZVBC);
>  			EXT_KEY(ZVKB);

Conor left a comment over here 
<https://lore.kernel.org/all/20240510-zve-detection-v5-6-0711bdd26c12@sifive.com/>.  
I think the best bet is to just merge this v5 on for-next now, though -- 
there's a bunch of patch sets touching ISA string parsing and IIUC that 
sub-extension parsing stuff is a pre-existing issue, and Clement's patch 
set still has some outstanding feedback to address.

So I think if we just go with this we're not regressing anything, we 
just have a bit more to clean up.  Maybe it's a little uglier now that 
userspace can see the sub-extensions, but I'd bet wacky ISA strings will 
be able to confuse us for a while.

I staged this so I can throw it at the tester, LMK if anyone has issues 
otherwise it'll show up on for-next.