Login

Linux Plumbers Conference 2026

5–7 Oct 2026
Europe/Prague timezone

2026

Supporting Heterogeneous VLEN on RISC-V: Lessons from SpacemiT K3

Not scheduled
20m
RISC-V MC RISC-V MC

Speakers

Mr Qiubing Zhang (SpacemiT)Mr Dong Xu (SpacemiT)

Description

Background

SpacemiT K3 is among the first production RVA23-compatible SoCs, shipping since late 2024. K3 features heterogeneous vector lengths:

  • 8× X100 cores: RV64GCV, VLEN=256, full RVA23 compliance, H-extension — general-purpose
  • 8× A100 cores: RV64GCV, VLEN=1024, no H-extension — AI/vector compute

Both core types implement RVV 1.0, but their incompatible vector register widths create a correctness issue: if a thread using vector instructions migrates between core types, its vector state corrupts. This isn't a performance concern — it's a data integrity problem.

Our current vendor-specific approach (CONFIG_SPACEMIT_HMP) enforces strict per-thread core-type binding. This works, but it's not upstream-friendly.

What SpacemiT Can Contribute

We can provide engineering data from 2+ years of HMP scheduling in production, including details on vector state management, signal frames, ptrace, and CPU hotplug. We'll also share real constraints — why certain approaches work or don't on actual silicon.

K3 development boards are available for testing, and we have deployment experience with 9+ distributions (Ubuntu, Debian, Fedora, openEuler, openKylin, etc.). We're committed to upstream patches based on community consensus.

Proposed Discussion Topics

1. Kernel mechanism options

We've explored several approaches and can share trade-offs:
- Generic heterogeneous-VLEN scheduling (similar to ARM capacity-aware)
- Cpuset/cgroup-based isolation
- ISA-capability-aware scheduling
- Userspace-only manual pinning

2. Vector state management

  • Should riscv_v_vsize be per-task or per-CPU?
  • Signal frame handling with variable VLEN?
  • ptrace behavior?

3. DT bindings and discoverability

  • Should VLEN capabilities be explicit in DT or runtime-discovered?
  • Standardization of per-core capability properties?

4. RVA23 ecosystem assumptions

  • Should RVA23 distributions assume uniform VLEN=256?
  • How should applications/libraries handle VLEN variability?
  • Kernel enforcement vs. userspace detection?

5. Should kernel support this at all?

  • Is this a legitimate use case (like ARM big.LITTLE) or a hardware constraint software shouldn't accommodate?

Session Format

We suggest a community-driven discussion. SpacemiT can provide engineering data and K3-specific details, while community maintainers lead the architectural direction. We'll share detailed technical background (2-3 pages) before the conference.

Why This Matters

  • RISC-V flexibility vs. portability: vendors can customize per-core ISA, but software must remain portable
  • This is solvable: ARM addressed big.LITTLE heterogeneity; RISC-V can too
  • Prevent fragmentation: if every vendor ships custom scheduling, distro/kernel maintenance becomes unsustainable

Desired Outcomes

  1. Community consensus on whether/how to support heterogeneous VLEN upstream
  2. DT binding direction for representing per-core capabilities
  3. Clear action items for follow-up patches and testing

Pre-Conference Materials

We will circulate 2-3 pages of technical background (HMP implementation, trade-offs, deployment observations, code pointers) to participants before the conference.

Reference: https://github.com/spacemit-com/linux

Author

Mr Qiubing Zhang (SpacemiT)

Co-authors

Mr Dong Xu (SpacemiT) Ms Yuting Nie (SpacemiT)

Presentation materials

There are no materials yet.