mbox series

[v9,00/13] riscv: Add support for xtheadvector

Message ID 20240806-xtheadvector-v9-0-62a56d2da5d0@rivosinc.com (mailing list archive)
Headers show
Series riscv: Add support for xtheadvector | expand

Message

Charlie Jenkins Aug. 7, 2024, 12:31 a.m. UTC
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

Comments

Conor Dooley Aug. 9, 2024, 10:31 p.m. UTC | #1
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?
indrek.kruusa@gmail.com Aug. 10, 2024, 6:58 p.m. UTC | #2
> 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.

Hi!
Regarding issues with Allwinner D1 CPU I tried to track down the problematic commit.
I tested with MangoPi MQ board (Allwinner D1s) and starting from this merge I can't
get beyond "Starting kernel...", ie. no output at all (and u-boot keeps restarting):

author	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 14:03:03 -0700
committer	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 14:03:03 -0700
commit	4527e837801e76bbb196bb3b19375d8e43d636be (patch)
tree	9c5b6c1a9f7d42530ff6140bceed737428ebac2a
parent	02d4df78c5ae70d283ebb4f78b9dcfdd4dfb71c2 (diff)
parent	678c607ecf8a9b1b2ea09c367877164ba66cb11f (diff)
download	linux-4527e837801e76bbb196bb3b19375d8e43d636be.tar.gz
Merge tag 'irq-msi-2024-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip


Previous merge boots fine:

author	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 13:50:30 -0700
committer	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 13:50:30 -0700
commit	02d4df78c5ae70d283ebb4f78b9dcfdd4dfb71c2 (patch)
tree	cb8d854f7987a864e3699a616e028953844181db
parent	045395d86acd02062b067bd325d4880391f2ce02 (diff)
parent	f7f56d59a3923e95bad2c49615a4d7313ed78314 (diff)
download	linux-02d4df78c5ae70d283ebb4f78b9dcfdd4dfb71c2.tar.gz
Merge tag 'irq-core-2024-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip


I hope that someone can take a look at it.

Thanks,
Indrek
Charlie Jenkins Aug. 13, 2024, 12:45 a.m. UTC | #3
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
Conor Dooley Aug. 13, 2024, 3:55 p.m. UTC | #4
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"?
Charlie Jenkins Aug. 19, 2024, 11:06 p.m. UTC | #5
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
Charlie Jenkins Aug. 19, 2024, 11:08 p.m. UTC | #6
On Sat, Aug 10, 2024 at 09:58:15PM +0300, indrek.kruusa@gmail.com wrote:
> > 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.
> 
> Hi!
> Regarding issues with Allwinner D1 CPU I tried to track down the problematic commit.
> I tested with MangoPi MQ board (Allwinner D1s) and starting from this merge I can't
> get beyond "Starting kernel...", ie. no output at all (and u-boot keeps restarting):
> 
> author	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 14:03:03 -0700
> committer	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 14:03:03 -0700
> commit	4527e837801e76bbb196bb3b19375d8e43d636be (patch)
> tree	9c5b6c1a9f7d42530ff6140bceed737428ebac2a
> parent	02d4df78c5ae70d283ebb4f78b9dcfdd4dfb71c2 (diff)
> parent	678c607ecf8a9b1b2ea09c367877164ba66cb11f (diff)
> download	linux-4527e837801e76bbb196bb3b19375d8e43d636be.tar.gz
> Merge tag 'irq-msi-2024-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 
> 
> Previous merge boots fine:
> 
> author	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 13:50:30 -0700
> committer	Linus Torvalds <torvalds@linux-foundation.org>	2024-03-11 13:50:30 -0700
> commit	02d4df78c5ae70d283ebb4f78b9dcfdd4dfb71c2 (patch)
> tree	cb8d854f7987a864e3699a616e028953844181db
> parent	045395d86acd02062b067bd325d4880391f2ce02 (diff)
> parent	f7f56d59a3923e95bad2c49615a4d7313ed78314 (diff)
> download	linux-02d4df78c5ae70d283ebb4f78b9dcfdd4dfb71c2.tar.gz
> Merge tag 'irq-core-2024-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 
> 
> I hope that someone can take a look at it.

Anup sent out a patch to fix this:
https://lore.kernel.org/lkml/20240817081218.2985171-1-apatel@ventanamicro.com/.

- Charlie

> 
> Thanks,
> Indrek
Conor Dooley Aug. 20, 2024, 4:42 p.m. UTC | #7
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.
indrek.kruusa@gmail.com Aug. 21, 2024, 3:41 p.m. UTC | #8
> Anup sent out a patch to fix this:
> https://lore.kernel.org/lkml/20240817081218.2985171-1-apatel@ventanamicro.com/.

Thank you for the feedback! As I'm seeing now from related e-mail threads then
the issue was reported quite a while back. Obviously I didn't dig deep enough
in linux-riscv archives and started to kind of bisect the issue by my self.
It's sad to read about how Allwinner doesn't provide much or any resources to
maintain the sofware support for its own chips. The next problem I have with
this CPU (D1s actually) is that u-boot compiled with binutils newer than v2.40
will not boot. But that's another story.


Thank you. I appreciate your help.
Indrek