| Message ID | 20240806-xtheadvector-v9-0-62a56d2da5d0@rivosinc.com |
|---|---|
| Headers | show |
| Series | riscv: Add support for xtheadvector | expand |
On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote: > xtheadvector is a custom extension that is based upon riscv vector > version 0.7.1 [1]. All of the vector routines have been modified to > support this alternative vector version based upon whether xtheadvector > was determined to be supported at boot. > > vlenb is not supported on the existing xtheadvector hardware, so a > devicetree property thead,vlenb is added to provide the vlenb to Linux. > > There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is > used to request which thead vendor extensions are supported on the > current platform. This allows future vendors to allocate hwprobe keys > for their vendor. > > Support for xtheadvector is also added to the vector kselftests. So uh, since noone seems to have brought it up, in the light of the issues with thead's vector implementation, (https://ghostwriteattack.com/) do we want to enable it at all?
On Fri, Aug 09, 2024 at 11:31:15PM +0100, Conor Dooley wrote: > On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote: > > xtheadvector is a custom extension that is based upon riscv vector > > version 0.7.1 [1]. All of the vector routines have been modified to > > support this alternative vector version based upon whether xtheadvector > > was determined to be supported at boot. > > > > vlenb is not supported on the existing xtheadvector hardware, so a > > devicetree property thead,vlenb is added to provide the vlenb to Linux. > > > > There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is > > used to request which thead vendor extensions are supported on the > > current platform. This allows future vendors to allocate hwprobe keys > > for their vendor. > > > > Support for xtheadvector is also added to the vector kselftests. > > So uh, since noone seems to have brought it up, in the light of the issues > with thead's vector implementation, (https://ghostwriteattack.com/) do we > want to enable it at all? I can make it clear in the kconfig that xtheadvector is succeptible to this attack and that it should be enabled with caution. I think we should let people that understand the risk to enable it. - Charlie
On Mon, Aug 12, 2024 at 05:45:30PM -0700, Charlie Jenkins wrote: > On Fri, Aug 09, 2024 at 11:31:15PM +0100, Conor Dooley wrote: > > On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote: > > > xtheadvector is a custom extension that is based upon riscv vector > > > version 0.7.1 [1]. All of the vector routines have been modified to > > > support this alternative vector version based upon whether xtheadvector > > > was determined to be supported at boot. > > > > > > vlenb is not supported on the existing xtheadvector hardware, so a > > > devicetree property thead,vlenb is added to provide the vlenb to Linux. > > > > > > There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is > > > used to request which thead vendor extensions are supported on the > > > current platform. This allows future vendors to allocate hwprobe keys > > > for their vendor. > > > > > > Support for xtheadvector is also added to the vector kselftests. > > > > So uh, since noone seems to have brought it up, in the light of the issues > > with thead's vector implementation, (https://ghostwriteattack.com/) do we > > want to enable it at all? > > I can make it clear in the kconfig that xtheadvector is succeptible to > this attack and that it should be enabled with caution. I think we > should let people that understand the risk to enable it. I think the clearest way might be "depends on BROKEN"?
On Tue, Aug 13, 2024 at 04:55:27PM +0100, Conor Dooley wrote: > On Mon, Aug 12, 2024 at 05:45:30PM -0700, Charlie Jenkins wrote: > > On Fri, Aug 09, 2024 at 11:31:15PM +0100, Conor Dooley wrote: > > > On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote: > > > > xtheadvector is a custom extension that is based upon riscv vector > > > > version 0.7.1 [1]. All of the vector routines have been modified to > > > > support this alternative vector version based upon whether xtheadvector > > > > was determined to be supported at boot. > > > > > > > > vlenb is not supported on the existing xtheadvector hardware, so a > > > > devicetree property thead,vlenb is added to provide the vlenb to Linux. > > > > > > > > There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is > > > > used to request which thead vendor extensions are supported on the > > > > current platform. This allows future vendors to allocate hwprobe keys > > > > for their vendor. > > > > > > > > Support for xtheadvector is also added to the vector kselftests. > > > > > > So uh, since noone seems to have brought it up, in the light of the issues > > > with thead's vector implementation, (https://ghostwriteattack.com/) do we > > > want to enable it at all? > > > > I can make it clear in the kconfig that xtheadvector is succeptible to > > this attack and that it should be enabled with caution. I think we > > should let people that understand the risk to enable it. > > I think the clearest way might be "depends on BROKEN"? Sorry for the delay, I am not sure if BROKEN is the best way of doing this. There is the generic CPU_MITIGATIONS config that I think we should use to handle this at boot time. This would allow generic kernels to be used on the platform, but a kernel config of "mitigations=off" would allow xtheadvector to be enabled. I'll look into this a bit more and send out a patch. Palmer merged a patch into for-next to enable GENERIC_CPU_VULNERABILITIES for riscv so I will add ghostwrite there as well. - Charlie
On Mon, Aug 19, 2024 at 04:06:08PM -0700, Charlie Jenkins wrote: > On Tue, Aug 13, 2024 at 04:55:27PM +0100, Conor Dooley wrote: > > On Mon, Aug 12, 2024 at 05:45:30PM -0700, Charlie Jenkins wrote: > > > On Fri, Aug 09, 2024 at 11:31:15PM +0100, Conor Dooley wrote: > > > > On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote: > > > > > xtheadvector is a custom extension that is based upon riscv vector > > > > > version 0.7.1 [1]. All of the vector routines have been modified to > > > > > support this alternative vector version based upon whether xtheadvector > > > > > was determined to be supported at boot. > > > > > > > > > > vlenb is not supported on the existing xtheadvector hardware, so a > > > > > devicetree property thead,vlenb is added to provide the vlenb to Linux. > > > > > > > > > > There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is > > > > > used to request which thead vendor extensions are supported on the > > > > > current platform. This allows future vendors to allocate hwprobe keys > > > > > for their vendor. > > > > > > > > > > Support for xtheadvector is also added to the vector kselftests. > > > > > > > > So uh, since noone seems to have brought it up, in the light of the issues > > > > with thead's vector implementation, (https://ghostwriteattack.com/) do we > > > > want to enable it at all? > > > > > > I can make it clear in the kconfig that xtheadvector is succeptible to > > > this attack and that it should be enabled with caution. I think we > > > should let people that understand the risk to enable it. > > > > I think the clearest way might be "depends on BROKEN"? > > Sorry for the delay, I am not sure if BROKEN is the best way of doing > this. There is the generic CPU_MITIGATIONS config that I think we should > use to handle this at boot time. This would allow generic kernels to be > used on the platform, but a kernel config of "mitigations=off" would > allow xtheadvector to be enabled. I'll look into this a bit more and > send out a patch. Palmer merged a patch into for-next to enable > GENERIC_CPU_VULNERABILITIES for riscv so I will add ghostwrite there > as well. Palmer also pointed out to me last week that not all implementations of xtheadvector actually have the flaw, so it makes sense to not depend on BROKEN. We should figure out exactly which CPUs are and are not vulnerable (Guo Ren hopefully will know) and permit enabling it without "mitagations=off" on the CPUs that are not vulnerable. Thanks, Conor.
xtheadvector is a custom extension that is based upon riscv vector version 0.7.1 [1]. All of the vector routines have been modified to support this alternative vector version based upon whether xtheadvector was determined to be supported at boot. vlenb is not supported on the existing xtheadvector hardware, so a devicetree property thead,vlenb is added to provide the vlenb to Linux. There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is used to request which thead vendor extensions are supported on the current platform. This allows future vendors to allocate hwprobe keys for their vendor. Support for xtheadvector is also added to the vector kselftests. Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> [1] https://github.com/T-head-Semi/thead-extension-spec/blob/95358cb2cca9489361c61d335e03d3134b14133f/xtheadvector.adoc --- This series is a continuation of a different series that was fragmented into two other series in an attempt to get part of it merged in the 6.10 merge window. The split-off series did not get merged due to a NAK on the series that added the generic riscv,vlenb devicetree entry. This series has converted riscv,vlenb to thead,vlenb to remedy this issue. The original series is titled "riscv: Support vendor extensions and xtheadvector" [3]. The series titled "riscv: Extend cpufeature.c to detect vendor extensions" is still under development and this series is based on that series! [4] I have tested this with an Allwinner Nezha board. I ran into issues booting the board after 6.9-rc1 so I applied these patches to 6.8. There are a couple of minor merge conflicts that do arrise when doing that, so please let me know if you have been able to boot this board with a 6.9 kernel. I used SkiffOS [1] to manage building the image, but upgraded the U-Boot version to Samuel Holland's more up-to-date version [2] and changed out the device tree used by U-Boot with the device trees that are present in upstream linux and this series. Thank you Samuel for all of the work you did to make this task possible. [1] https://github.com/skiffos/SkiffOS/tree/master/configs/allwinner/nezha [2] https://github.com/smaeul/u-boot/commit/2e89b706f5c956a70c989cd31665f1429e9a0b48 [3] https://lore.kernel.org/all/20240503-dev-charlie-support_thead_vector_6_9-v6-0-cb7624e65d82@rivosinc.com/ [4] https://lore.kernel.org/lkml/20240719-support_vendor_extensions-v3-4-0af7587bbec0@rivosinc.com/T/ --- Changes in v9: - Rebase onto palmer's for-next - Fix sparse error in arch/riscv/kernel/vendor_extensions/thead.c - Fix maybe-uninitialized warning in arch/riscv/include/asm/vendor_extensions/vendor_hwprobe.h - Wrap some long lines - Link to v8: https://lore.kernel.org/r/20240724-xtheadvector-v8-0-cf043168e137@rivosinc.com Changes in v8: - Rebase onto palmer's for-next - Link to v7: https://lore.kernel.org/r/20240724-xtheadvector-v7-0-b741910ada3e@rivosinc.com Changes in v7: - Add defs for has_xtheadvector_no_alternatives() and has_xtheadvector() when vector disabled. (Palmer) - Link to v6: https://lore.kernel.org/r/20240722-xtheadvector-v6-0-c9af0130fa00@rivosinc.com Changes in v6: - Fix return type of is_vector_supported()/is_xthead_supported() to be bool - Link to v5: https://lore.kernel.org/r/20240719-xtheadvector-v5-0-4b485fc7d55f@rivosinc.com Changes in v5: - Rebase on for-next - Link to v4: https://lore.kernel.org/r/20240702-xtheadvector-v4-0-2bad6820db11@rivosinc.com Changes in v4: - Replace inline asm with C (Samuel) - Rename VCSRs to CSRs (Samuel) - Replace .insn directives with .4byte directives - Link to v3: https://lore.kernel.org/r/20240619-xtheadvector-v3-0-bff39eb9668e@rivosinc.com Changes in v3: - Add back Heiko's signed-off-by (Conor) - Mark RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 as a bitmask - Link to v2: https://lore.kernel.org/r/20240610-xtheadvector-v2-0-97a48613ad64@rivosinc.com Changes in v2: - Removed extraneous references to "riscv,vlenb" (Jess) - Moved declaration of "thead,vlenb" into cpus.yaml and added restriction that it's only applicable to thead cores (Conor) - Check CONFIG_RISCV_ISA_XTHEADVECTOR instead of CONFIG_RISCV_ISA_V for thead,vlenb (Jess) - Fix naming of hwprobe variables (Evan) - Link to v1: https://lore.kernel.org/r/20240609-xtheadvector-v1-0-3fe591d7f109@rivosinc.com --- Charlie Jenkins (12): dt-bindings: riscv: Add xtheadvector ISA extension description dt-bindings: cpus: add a thead vlen register length property riscv: dts: allwinner: Add xtheadvector to the D1/D1s devicetree riscv: Add thead and xtheadvector as a vendor extension riscv: vector: Use vlenb from DT for thead riscv: csr: Add CSR encodings for CSR_VXRM/CSR_VXSAT riscv: Add xtheadvector instruction definitions riscv: vector: Support xtheadvector save/restore riscv: hwprobe: Add thead vendor extension probing riscv: hwprobe: Document thead vendor extensions and xtheadvector extension selftests: riscv: Fix vector tests selftests: riscv: Support xtheadvector in vector tests Heiko Stuebner (1): RISC-V: define the elements of the VCSR vector CSR Documentation/arch/riscv/hwprobe.rst | 10 + Documentation/devicetree/bindings/riscv/cpus.yaml | 19 ++ .../devicetree/bindings/riscv/extensions.yaml | 10 + arch/riscv/Kconfig.vendor | 26 ++ arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 3 +- arch/riscv/include/asm/cpufeature.h | 2 + arch/riscv/include/asm/csr.h | 15 + arch/riscv/include/asm/hwprobe.h | 3 +- arch/riscv/include/asm/switch_to.h | 2 +- arch/riscv/include/asm/vector.h | 225 +++++++++++---- arch/riscv/include/asm/vendor_extensions/thead.h | 42 +++ .../include/asm/vendor_extensions/thead_hwprobe.h | 19 ++ .../include/asm/vendor_extensions/vendor_hwprobe.h | 37 +++ arch/riscv/include/uapi/asm/hwprobe.h | 3 +- arch/riscv/include/uapi/asm/vendor/thead.h | 3 + arch/riscv/kernel/cpufeature.c | 52 +++- arch/riscv/kernel/kernel_mode_vector.c | 8 +- arch/riscv/kernel/process.c | 4 +- arch/riscv/kernel/signal.c | 6 +- arch/riscv/kernel/sys_hwprobe.c | 5 + arch/riscv/kernel/vector.c | 24 +- arch/riscv/kernel/vendor_extensions.c | 10 + arch/riscv/kernel/vendor_extensions/Makefile | 2 + arch/riscv/kernel/vendor_extensions/thead.c | 18 ++ .../riscv/kernel/vendor_extensions/thead_hwprobe.c | 19 ++ tools/testing/selftests/riscv/vector/.gitignore | 3 +- tools/testing/selftests/riscv/vector/Makefile | 17 +- .../selftests/riscv/vector/v_exec_initval_nolibc.c | 94 +++++++ tools/testing/selftests/riscv/vector/v_helpers.c | 68 +++++ tools/testing/selftests/riscv/vector/v_helpers.h | 8 + tools/testing/selftests/riscv/vector/v_initval.c | 22 ++ .../selftests/riscv/vector/v_initval_nolibc.c | 68 ----- .../selftests/riscv/vector/vstate_exec_nolibc.c | 20 +- .../testing/selftests/riscv/vector/vstate_prctl.c | 305 +++++++++++++-------- 34 files changed, 901 insertions(+), 271 deletions(-) --- base-commit: 7c08a2615f149f64fb1bb4660997e152fb3a11a7 change-id: 20240530-xtheadvector-833d3d17b423