RISC-V: "Illegal instruction" crash when vector instructions detected by V8

[sxa]

Version

v26.5.0 (but any v26 and above is affected)

Platform

Linux firefly 6.18.3 #2 SMP PREEMPT_DYNAMIC Wed May 13 16:58:11 CST 2026 riscv64 GNU/Linux

Subsystem

V8

What steps will reproduce the bug?

run npm or any node-gyp on a SpacemiT-K3 board. Also fails in the build-addons step with make run-ci as that executes node-gyp. Other boards such as the SpacemiT-K1 do not show the crash (Both should have vector instructions available)

How often does it reproduce? Is there a required condition?

100% of the time

What is the expected behavior? Why is that the expected behavior?

There should be no crash when running npm

What do you see instead?

Illegal Instruction

Additional information

Based on the fact that sxa@1ecdd38 fixes it seems likely that this was introduced as part of the vector instructions introduced in v8/v8@de361fd - I haven't yet tracked it down to any specific operation in that function. At the moment I've also only determined that it fixes the initial crash and hopefully that doesn' uncover more issues.

FYI @luhenry @luyahan @nodejs/platform-riscv64

Split out from nodejs/build#4099 (comment)

[sxa]

That is likely not the only problem as even with that bypass of the vector instructions in that file enabled there are still Illegal instruction failures in some test cases e.g.

=== release test-http-set-global-proxy-from-env-fetch ===
Path: client-proxy/test-http-set-global-proxy-from-env-fetch
[CLOSE] null SIGILL
node:internal/modules/run_main:107
 triggerUncaughtException(
 ^

[sxa]

Bypassing all of the RVV stuff in V8 (sxa@88497e2) allows all of the tests to complete without illegal instruction errors

[gounthar]

I might be well off here since I've only had a few hours on a K3 (remote access back in March, benchmarking llama.cpp), but there's one thing from that session that might be worth ruling out.

The K3 is heterogeneous in a way that matters for RVV: the X100 cores are VLEN 256 and the A100 cores are VLEN 1024, on the same chip. I measured both, and RVV code ran fine on each of them, so it isn't that the vector unit is missing or broken.

What I never tested is what happens when a long-running process migrates between the two clusters. If V8 probes VLEN once at startup, or if vector state doesn't survive migration between cores with different VLEN, then a later vector instruction could trap. That would fit vmv.s.x v24, x19 being plain baseline RVV 1.0 rather than anything exotic, and it would also fit the standalone Highway suite passing, since a short test is far less likely to migrate than a full npm run.

If it's worth five minutes, pinning with taskset to X100-only cores and then A100-only should settle it. If the SIGILL survives pinning, I'm wrong and it really is codegen.

You've spent a lot more time inside this than I have, so there's a good chance you've already ruled it out.

[sxa]

If it's worth five minutes, pinning with taskset to X100-only cores and then A100-only should settle it. If the SIGILL survives pinning, I'm wrong and it really is codegen.

Yeah that was one of my first thoughts too, but pinning to A100 didnt' seem to change the behaviour. I'll give it another try tomorrow just to confirm though!

[sxa]

Confirmed again that it does still crash with Illegal Instruction on the A100 cores, albeit with slightly different output as it includes a bit of stack trace - here's the output since I hadn't logged it previously:

$ ./npm
Illegal instruction
$ systemd-run --scope -p AllowedCPUs=8-15 ./npm 
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
[...
==== AUTHENTICATION COMPLETE ====
Running as unit: run-p844737-i844738.scope; invocation ID: ecab0467508f437a9dc23e002c27f250


#
# Fatal error in , line 0
# unimplemented code
#
#
#
#FailureMessage Object: 0x3fe36f2e98
----- Native stack trace -----

 1: 0x2ac04adb36 [npm]
 2: 0x2ac1ec2816 V8_Fatal(char const*, ...) [npm]
 3: 0x2ac12359c0 [npm]
 4: 0x2ac0caa598 [npm]
 5: 0x2ac0ca928c [npm]
 6: 0x2ac0ca899a [npm]
 7: 0x2ac0cdd770 [npm]
 8: 0x2ac0cdda24 [npm]
 9: 0x2ac0cdb45c [npm]
10: 0x2ac0cdb318 [npm]
11: 0x2ac0cfe3ee [npm]
12: 0x2ac139ab04 [npm]
Illegal instruction

[RevySR]

Confirmed again that it does still crash with Illegal Instruction on the A100 cores, albeit with slightly different output as it includes a bit of stack trace - here's the output since I hadn't logged it previously:

$ ./npm
Illegal instruction
$ systemd-run --scope -p AllowedCPUs=8-15 ./npm 
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
[...
==== AUTHENTICATION COMPLETE ====
Running as unit: run-p844737-i844738.scope; invocation ID: ecab0467508f437a9dc23e002c27f250


#
# Fatal error in , line 0
# unimplemented code
#
#
#
#FailureMessage Object: 0x3fe36f2e98
----- Native stack trace -----

 1: 0x2ac04adb36 [npm]
 2: 0x2ac1ec2816 V8_Fatal(char const*, ...) [npm]
 3: 0x2ac12359c0 [npm]
 4: 0x2ac0caa598 [npm]
 5: 0x2ac0ca928c [npm]
 6: 0x2ac0ca899a [npm]
 7: 0x2ac0cdd770 [npm]
 8: 0x2ac0cdda24 [npm]
 9: 0x2ac0cdb45c [npm]
10: 0x2ac0cdb318 [npm]
11: 0x2ac0cfe3ee [npm]
12: 0x2ac139ab04 [npm]
Illegal instruction

This method is incorrect. The vendor kernel has hacked the vector context-related parts to enable different vlen sizes, so running RVV on an A100 may not work.
Another issue is that scheduling may fail on CPUs 8-15, where the behavior is controlled by the HMP[4] module.

1: spacemit-com/linux-6.18@ce988b8
2: spacemit-com/linux-6.18@33024f2
3: spacemit-com/linux-6.18@2cb5950
4: spacemit-com/linux-6.18@6968f3e

[gounthar]

That stack trace helps, and I think it points somewhere slightly different from "instructions incompatible with the K3".

Frame 2 is V8_Fatal, and the message is unimplemented code. That string is V8's own: kUnimplementedCodeMessage in deps/v8/src/base/logging.h:66, with #define UNIMPLEMENTED() FATAL(::v8::base::kUnimplementedCodeMessage) right below it at line 70. So V8 is deliberately aborting, and the Illegal instruction you see is just how V8_Fatal ends the process on riscv64 rather than the CPU rejecting anything.

There is one UNIMPLEMENTED() in the riscv64 backend that RVV codegen reaches. In deps/v8/src/codegen/riscv/assembler-riscv.h, VU::SetSimd128 (line 625), SetSimd128Half (661) and SetSimd128x2 (690) each switch on CpuFeatures::vlen() with cases for 128, 256 and 512, then static_assert(kMaxRvvVLEN <= 512) and UNIMPLEMENTED() in the default. kMaxRvvVLEN is 512, in deps/v8/src/codegen/riscv/base-constants-riscv.h:343. The value is not a build-time assumption either: deps/v8/src/base/cpu.cc probes the hardware at startup with __riscv_vlenb() (line 64, used at line 1091).

When I had remote access to a K3 back in March, the A100 cores measured VLEN 1024. If the probe returns 1024, no case matches and the first SIMD path taken aborts. That would fit everything in this thread: the K1 at 256 is fine, your commit disabling the RVV paths fixes it, and it has nothing to do with which cluster the process ends up on.

It would also explain the qemu result. As far as I know qemu defaults to VLEN 128 unless you pass vlen= explicitly, so it would take the first case and never reach the abort. Not reproducing under emulation is what this theory predicts rather than evidence against it.

@RevySR, thank you for the kernel pointers, and that also means the test I suggested earlier was a bad one: if HMP controls placement then pinning proves nothing either way, and sxa's A100 run not changing anything was never evidence against VLEN.

Something that does not depend on scheduling: build a tiny program that prints __riscv_vlenb() * 8 and run it a number of times on that machine. If 1024 ever comes back, V8 has no case for it and the abort follows wherever the code lands. If it is always 256, I am wrong and this is ordinary codegen after all.

I do not have any K3 hardware, the March session was remote access on someone else's board and mine is a few weeks out, so I cannot check this myself. You have both been inside this a lot longer than I have, so happy to be told I am chasing the wrong UNIMPLEMENTED().

[sxa]

Something that does not depend on scheduling: build a tiny program that prints __riscv_vlenb() * 8 and run it a number of times on that machine. If 1024 ever comes back, V8 has no case for it and the abort follows wherever the code lands. If it is always 256, I am wrong and this is ordinary codegen after all.

It consistently returns 256 on the (default) X100 cores and when run under systemd-run --scope -p AllowedCPUs=8-15 consistently returns 1024.

happy to be told I am chasing the wrong UNIMPLEMENTED().

I wouldn't claim to be any more of a V8 expert at the moment than you, but that analysis sounds feasible ...

[sxa]

I ran a build with some crude debug sxa@6ad0dbd to clarify what V8 was identifying on the X100 cores in case it was incorrect:

23:14:12 RISC-V CPU Vector length detected as 256
23:14:12 supports_wasm_simd_128=1, vlen=256
23:14:12 RISC-V Extension zba=0,zbb=0,zbs=0,ZICOND=0

(Probably not useful for anything else but if anyone wants the build with that patch in it to run elsewhere ping me on Slack - it's in the CI but that's not publicly visible)

[sxa]

@luyahan Do you have any advice/guides on setting up a V8 build environment on RISC-V (ideally natively - I'm struggling to get a suitable build environemnt for it at the moment)? Also are you aware of any problems like this on K3 hardware? Noting that Node.js is currently using V8 14.6