Skip to content
STIMSMITH

RISC-V Vector Extension

Concept WIKI v1 · 7/29/2026

The RISC-V Vector Extension (RVV) is a RISC-V ISA extension for vector/SIMD-style computation. Evidence highlights RVV 1.0 support in virtual platforms, QEMU implementation details around vector state dirtiness, vector CSR state such as vstart, and current software work on NEON-to-RVV migration and AI workload tuning.

Overview

The RISC-V Vector Extension is a vector extension for the RISC-V architecture. It is commonly abbreviated RVV and appears in both software-porting and workload-optimization contexts, including migration of ARM NEON intrinsic code to RVV intrinsics and tensor-program optimization for RISC-V vector units. Public research describes RVV as relevant for performance-oriented SIMD migration and for acceleration of AI workloads on RISC-V CPUs. [1][2]

Programming and optimization context

RVV differs from fixed-width SIMD programming models in that migration work must account for vector-length-agnostic behavior. One public study on SIMDe-based migration from ARM NEON to RVV reports type-conversion strategies that consider RVV's vector-length-agnostic architecture, and function-conversion strategies based on generated RVV code. In experiments with Google XNNPACK, the enhanced SIMDe approach reported speedups from 1.51x to 5.13x compared with the original SIMDe path that did not use customized RVV implementations. [1]

A separate public study integrates RVV into TVM's MetaSchedule framework to map AI workloads onto RISC-V vector units. It reports mean execution-latency improvements of 46% over GCC autovectorization and 29% over muRISCV-NN on tested FPGA-based RISC-V SoCs, and 35% faster mappings on average than LLVM on a commercial RISC-V SoC implementing RVV 1.0. [2]

Architectural state and mstatus.VS

RVV has architectural vector state, including vector CSRs. A QEMU development patch quotes the Vector specification section 3.2: when mstatus.VS is Initial or Clean, executing any instruction that changes vector state, including vector CSRs, changes mstatus.VS to Dirty. [3]

The same patch discusses vstart as vector CSR state. It notes that RVV load/store translation paths can change vector state even for store operations, because stores set env->vstart to zero after execution in QEMU helper code, which is a vector CSR state change. [3]

QEMU implementation notes

In QEMU, RVV translation code is implemented in target/riscv/insn_trans/trans_rvv.c.inc. A February 2024 patch changed several RVV load/store translation functions so that they always call mark_vs_dirty(s) rather than doing so only for non-store operations. The affected translation helpers in the patch are:

  • ldst_us_trans()
  • ldst_stride_trans()
  • ldst_index_trans()
  • ldst_whole_trans()

The patch states that all of these can change vector state regardless of whether the operation is a store. It also identifies the fix as related to an earlier QEMU change titled target/riscv: rvv-1.0: add translation-time vector context status. [3]

Implementations and validation contexts

Evidence from a CHERI-RISC-V virtual-platform presentation describes RISC-V VP++ as an extensible, configurable, open-source SystemC-based RISC-V virtual prototype supporting RISC-V 32-bit and 64-bit single-/multi-core configurations and Vector Extension (RVV) version 1.0. [4]

Security and compatibility testing also intersects with RVV. The RISCover paper excerpt lists discovered issues associated with the Vector extension, including denial-of-service findings on X60 and C908 CPUs, ISA incompatibilities involving Vector and Base ISA on C908/C910, and QEMU segfaults in QEMU 8.2.2 and 9.0.0 involving Vector and cache operations. [5]

Related concepts

  • RISC-V: RVV is part of the RISC-V ISA ecosystem.
  • mstatus.VS: Privileged status field tracking vector context status; vector-state changes can make it Dirty.
  • vector CSR state: Includes vector CSRs such as vstart, whose modification counts as vector-state change.
  • translation-time vector context status: QEMU implementation concept referenced by the RVV dirty-state fix.
  • QEMU and trans_rvv.c.inc: QEMU implements RVV translation logic in trans_rvv.c.inc.

LINKED ENTITIES

6 links
trans_rvv.c.inc IMPLEMENTS
mstatus.VS PART_OF
vector CSR state PART_OF
translation-time vector context status PART_OF
RISC-V PART_OF
QEMU IMPLEMENTS

CITATIONS

5 sources
5 citations
[1] SIMDe-based NEON-to-RVV migration work treats RVV as vector-length agnostic and reported 1.51x to 5.13x speedups on Google XNNPACK versus original SIMDe without customized RVV conversions. SIMD Everywhere Optimization from ARM NEON to RISC-V Vector Extensions
[2] TVM MetaSchedule integration for RVV targets RISC-V vector units for AI workloads and reported mean latency improvements of 46% over GCC autovectorization, 29% over muRISCV-NN, and 35% over LLVM mappings on a commercial RVV 1.0 SoC. Tensor Program Optimization for the RISC-V Vector Extension Using Probabilistic Programs
[3] The Vector specification rule quoted in the QEMU patch says vector-state-changing instructions, including vector CSR changes, move mstatus.VS from Initial or Clean to Dirty; QEMU changed RVV load/store translation helpers to always call mark_vs_dirty because stores can reset vstart. [PATCH 1/3] trans_rvv.c.inc: write CSRs must call mark_vs_dirty() too
[4] RISC-V VP++ is described as an open-source SystemC-based RISC-V virtual prototype supporting RVV version 1.0. Bringing CHERI Capabilities to Life in a Virtual Platform: CHERI-RISC-V VP++
[5] RISCover reported Vector-related findings including denial-of-service cases, ISA incompatibilities involving Vector and Base ISA, and QEMU segfaults involving Vector and cache operations. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs