After RVA23: CFI, the Three Matrix Extension Routes, and What RVA23.1 Adds — Canonical's Distro View
RVA23 was the big ratification of the decade: the profile that finally made vector 1.0, hypervisor, and a curated extension set mandatory for application-class RISC-V silicon. The obvious question every engineering team now asks is what comes next — and who decides. Canonical's Jon Taylor published a precise answer on the Ubuntu blog this week (Evolution of the RISC-V ISA. What next after RVA23?, September 15, 2026), and it is the best distro-side map of the post-RVA23 landscape we have seen. This article annotates it with the official spec references, because the three areas it identifies — security (CFI), performance (matrix), and minor profile revisions (RVA23.1) — are exactly where silicon and software roadmaps will collide over the next two years.
The Three Fronts of Post-RVA23 Innovation
Canonical groups upcoming ISA work into three buckets, and the grouping is worth adopting verbatim:
| Area | What it covers | Status per Canonical |
|---|---|---|
| Security extensions | Control Flow Integrity (CFI) — Zicfilp + Zicfiss | CFI ratified by RISC-V International in 2024; other security extensions moving toward ratification in 2026–2027 |
| Performance extensions | Matrix compute — three routes: IME, VME, AME | At different maturity levels; ratification pending for some routes |
| Minor profile revisions | RVA23.1 — new development and expansion options | In public review (RVA23.1 / RVB23.1 announcement on riscv.org isa-dev) |
The key framing: RVA23 provides the deployment baseline "for many years to come," and RVA23 binaries will run on newer silicon — Canonical is explicit that there is no backwards-compatibility cliff. Innovation lands around the baseline, not through it.
Control Flow Integrity: Zicfilp + Zicfiss
CFI is a lightweight, optional extension pair targeting the dominant exploit families of the last two decades: Return-Oriented Programming (ROP) and Call/Jump-Oriented Programming (COP/JOP). Both attacks redirect control flow to unintended code locations and chain existing code snippets ("gadgets") from the program binary to run arbitrary logic. CFI does not try to stop data corruption; it stops the corrupted data from steering execution.
| Extension | Mechanism | Attack it stops |
|---|---|---|
| Zicfilp | Landing pads. Indirect calls/jumps must land on an annotated landing-pad instruction. A branch to any location that is not a landing pad traps — an attacker cannot jump to an arbitrary mid-function offset. | COP/JOP — hijacked indirect branches (function pointers, jump tables) |
| Zicfiss | Shadow stack. On every function call the return address is stored twice — on the normal stack and on a separate shadow stack. On return, the two values are compared; a mismatch traps before the hijacked return executes. | ROP — stack-smashing that overwrites the saved return address |
They are two independent extensions: a core can implement Zicfilp without Zicfiss and vice versa. That matters for silicon sizing — landing-pad checking is cheap; a shadow stack needs a second return-address storage that must itself be protected.
Backward Compatibility: The Zimop Caveat
This is the most operationally interesting paragraph in Canonical's post. The extensions were designed to maximize compatibility with existing RVA23 hardware: where the hardware implementation is absent, CFI instructions are ignored (treated as no-ops). That lets compilers and toolchains ship CFI instrumentation today, before any CFI silicon exists — the binaries run everywhere, and the protection silently activates on the first CFI-capable core.
One trap: on pre-RVA23 hardware that lacks Zimop (may-be-operations support), Zicfiss instructions will trap instead of being ignored. Canonical is honest about the trade-off — no-op encodings are "not ideal for performance and code size" — but the net position is a pragmatic one: software (compiler toolchains) can adopt first, and "as soon as the hardware is available it will 'just work'." GCC and LLVM already support CFI today, per Canonical.
Matrix: Three Routes, Three OS Bills
AI/ML is the growth engine of RISC-V, and nearly every AI workload bottoms out in matrix math. But a smart-sensor endpoint and a training server need very different matrix machinery, so RISC-V is growing three distinct routes rather than one mandatory monolith:
| Route | Full name | Architectural state | OS impact (context switch) | Toolchain effort per Canonical |
|---|---|---|---|---|
| VME | Vector Matrix Extension | Same as standard vector state — no new registers beyond what RVV already saves | None. No OS changes needed. | Relatively simple to support |
| IME | Integrated Matrix Extension | Extends the vector register file and adds additional result registers | OS changes required. Kernel must save/restore the added registers on context switch. | Moderate; intrinsics-first is realistic |
| AME | Attached Matrix Extension | Completely new register file, separate from vector | OS changes required. Largest new state to manage. | "A lot of work" per Canonical |
The discriminator is who pays for the state. VME reuses the vector context switch that kernels already perform, so a VME-equipped core is invisible to the OS. IME and AME both add architectural state, which means the kernel's context-switch path must be taught about the new registers — and until that lands, an OS that ignores them will silently corrupt matrix state across task switches.
This taxonomy maps directly onto silicon we have covered on this site: SpacemiT's K3 implements IME on its A100 AI cores (IME 1.0 per-core private, IME 2.0 dual-core shared, per the K3 preview paper), which is why deepin 25's K3 port and the MNN inference stack both required SpacemiT-patched toolchains. NVIDIA's Hot Chips 2026 platform contract for RISC-V host CPUs, on the other hand, references the VME-family route for matrix operations. The two routes are not competitors for the same socket — IME targets integrated AI CPUs, VME/AME target different points in the scale spectrum. For the ratification-calendar view of the same three routes (including the VME internal-review dates), see our earlier article RISC-V Matrix Extensions in 2026: IME, VME and AME; this post is the distro/toolchain view, that one is the standards-timeline view.
Runtime Discovery with sys_riscv_hwprobe()
Because the same library may run on VME, IME, or AME silicon — or none of the above — Canonical highlights the sys_riscv_hwprobe() Linux system call (which their earlier custom-instructions article introduced): the application asks the kernel which extensions are implemented, and picks the right code path at runtime. The practical pattern is one library, multiple compiled implementations, runtime selection:
/* Illustrative sketch of the riscv_hwprobe UAPI shape.
Exact key/value semantics: linux/hwprobe.h UAPI headers and the
Ubuntu "custom instructions" article linked in Sources. */
#include <sys/hwprobe.h>
struct riscv_hwprobe pairs[] = {
{ .key = RISCV_HWPROBE_KEY_IMA_EXT_0, .value = 0 },
};
__riscv_hwprobe(pairs, 1, 0, NULL, 0);
if (pairs[0].value & HWPROBE_EXT_ZVFH /* example bit */) {
/* take the matrix-accelerated path */
} else {
/* fall back to the scalar/RVV path */
}Canonical's conclusion for library authors: compile support for multiple implementation choices into the same binary, and let hwprobe select at runtime. That is the same dispatch model Arm has used with HWCAP for years — RISC-V gets it as a first-class UAPI rather than an afterthought.
Out-of-Tree Work While We Wait: Xuantie
Standard ratification takes time, and vendors do not wait. Canonical points to Xuantie (Alibaba DAMO Academy), which is working on a version of the matrix extensions in the open (XUANTIE-RV/riscv-matrix-extension-spec on GitHub) and has developed toolchain support in a private GCC branch — the classic out-of-tree pattern: spec public, toolchain vendor-first. We flagged the same pattern in our K3 coverage; it is the price of being early, and the reason distro integration always trails silicon announcements.
RVA23.1: Stability by Design
Profile minor revisions are where RISC-V's governance philosophy shows most clearly: minor revisions deliberately include no new mandatory extensions. That is what keeps RVA23 software stable for years. Instead, each minor revision introduces two kinds of optional items:
| Option type | Meaning | Why it exists |
|---|---|---|
| Development option | A precursor that is expected to become mandatory in a future profile | Gives software a "softer landing" — ship support now, before the hardware requirement bites |
| Expansion option | Intended to remain optional permanently | Targets applications where implementation cost is justified but is too large to mandate for all profile users |
RVA23.1 adds three development options and two expansion options. Canonical singles out the three that matter for Ubuntu (and, by extension, every general-purpose distro):
| Extension | What it does | Who benefits |
|---|---|---|
| Ssdbltrap (Double Trap Handling) | Covers a narrow but nasty corner case: if a second trap occurs while the first trap handler is still in a non-reentrant state, the system can crash and corrupt memory. Ssdbltrap lets machine mode or hypervisor mode safely catch the second trap. | Kernel/hypervisor robustness — fewer fatal double-fault paths, lower memory-corruption risk |
| Sscfg (Supervisor Counter Delegation) | Lets supervisor (S-mode) manage and configure performance counter registers directly, without a round-trip through machine-mode firmware. | Linux perf — measurable profiling overhead reduction |
| Ssctr (Control Transfer Records) | Records branch history in hardware for much better branch profiling — the enabling mechanism for Profile-Guided Optimization (PGO) on RISC-V. | Compilers and profilers; PGO requires upstream Linux kernel support to expose branch record buffers via perf — patches exist but are not yet accepted upstream |
Note the honest dependency chain in the Ssctr row: the extension is one leg of a three-legged stool — silicon support, kernel plumbing (perf), and compiler/profiler integration. Shipping any one without the others buys nothing, which is exactly why the "development option" staging exists.
Toolchain Status, Summarized
| Group | Toolchain status per Canonical |
|---|---|
| CFI | GCC and LLVM support it already today |
| Matrix | Two approaches: compiler intrinsics (assembly-like, works now) vs. having the compiler automatically target matrix instructions (harder). VME relatively simple; AME a lot of work. Out-of-tree vendor work exists (Xuantie private GCC branch) while ratification is pending. |
| RVA23.1 | Some features accessed via intrinsics or CSR assembly rather than code generation; extensions like Ssctr interface directly to compiler profilers |
What This Means for Builders
- Ship CFI-ready binaries now. GCC/LLVM support exists; on RVA23+ hardware the instructions are ignored until the core implements them. Just verify your fleet is genuinely RVA23+ (or at least Zimop-capable) before enabling Zicfiss instrumentation.
- Treat matrix as a per-silicon contract, not an ISA checkbox. Ask vendors which route they implement (VME / IME / AME), what the kernel context-switch story is, and whether the toolchain is upstream, out-of-tree, or intrinsics-only.
- Design libraries for runtime dispatch.
sys_riscv_hwprobe()is the supported discovery mechanism — bake multi-path libraries into your porting plan from day one. - Watch the RVA23.1 public review. Ssdbltrap, Sscfg, and Ssctr are cheap for silicon to adopt early (they are development options precisely to encourage that) and pay off in robustness and profiling as soon as kernel support lands.
Conclusion
Canonical's post is refreshingly free of hype: RVA23 holds as the common platform, backwards compatibility is preserved by construction, and the interesting work proceeds on three clearly separated tracks — CFI for security, three matrix routes for AI, and staged minor revisions for stability. For engineering teams the practical takeaway is that the software can move first: CFI toolchains exist today, hwprobe-based dispatch is a UAPI you can use today, and the development-option mechanism exists precisely so that today's optional work becomes tomorrow's mandatory baseline without breaking anyone's binaries.
RVA23 是这十年最重要的一次标准批准：它首次将向量 1.0、Hypervisor 以及一组精心挑选的扩展定为应用级 RISC-V 芯片的强制基线。现在每个工程团队最关心的问题是：接下来是什么？谁在决定？ Canonical 的 Jon Taylor 本周在 Ubuntu 官方博客发表了《Evolution of the RISC-V ISA. What next after RVA23?》（2026 年 9 月 15 日），这是目前最好的发行版视角的 RVA23 之后路线图。本文在它的基础上补充官方规格文档链接进行注解——它指出的三个方向（安全 CFI、性能矩阵、小版本修订 RVA23.1）正是未来两年芯片路线图与软件路线图碰撞最剧烈的地方。
RVA23 之后创新的三个战线
| 领域 | 覆盖内容 | Canonical 给出的状态 |
|---|---|---|
| 安全扩展 | 控制流完整性（CFI）—— Zicfilp + Zicfiss | CFI 已于 2024 年获 RISC-V International 批准；其他安全扩展正走向 2026–2027 年批准 |
| 性能扩展 | 矩阵计算——三条路线：IME、VME、AME | 成熟度不一；部分路线批准仍在进行中 |
| 小版本修订 | RVA23.1——新增开发选项与扩展选项 | 公开评审中（RVA23.1 / RVB23.1 公告见 riscv.org isa-dev） |
关键框架：RVA23 是未来多年稳定的部署基线，且 RVA23 二进制可以直接跑在新硅片上——Canonical 明确表示不存在向后兼容断崖。创新围绕基线展开，而不是穿过它。
控制流完整性：Zicfilp + Zicfiss
CFI 是一对轻量级可选扩展，针对的是过去二十年最主要的漏洞利用家族：返回导向编程（ROP）与调用/跳转导向编程（COP/JOP）。两类攻击都把控制流重定向到意外的代码位置，并串联程序二进制中现成的代码片段（"gadget"）来执行任意逻辑。CFI 不阻止数据被篡改，它阻止被篡改的数据劫持执行流。
| 扩展 | 机制 | 阻止的攻击 |
|---|---|---|
| Zicfilp | 着陆垫（Landing pad）。间接调用/跳转必须落在带注解的着陆垫指令上；跳到任何非着陆垫位置都会触发陷入（trap）——攻击者无法跳到函数内部任意偏移。 | COP/JOP——被劫持的间接分支（函数指针、跳转表） |
| Zicfiss | 影子栈（Shadow stack）。每次函数调用时返回地址存两份——常规栈与独立影子栈各一份；返回时两者比对，不一致则在被劫持的返回执行前陷入。 | ROP——覆写栈上保存的返回地址的栈溢出攻击 |
二者是相互独立的扩展：核心可以实现 Zicfilp 而不实现 Zicfiss，反之亦然。这对芯片面积有意义——着陆垫检查很便宜，而影子栈需要一份自身也要被保护的返回地址存储。
向后兼容：Zimop 陷阱
这是 Canonical 文中运营层面最有意思的一段。这对扩展被设计为最大化兼容现有 RVA23 硬件：硬件未实现时，CFI 指令被忽略（当作 NOP）。这意味着编译器和工具链可以今天就输出 CFI 插桩——二进制在哪都能跑，保护在第一颗支持 CFI 的核心上自动激活。
一个陷阱：在不支持 Zimop（may-be-operations）的 pre-RVA23 硬件上，Zicfiss 指令会陷入而不是被忽略。Canonical 也不回避代价——NOP 编码"对性能和代码体积不理想"——但净结论很务实：软件（编译器工具链）先行，"硬件一到就能直接工作"。据 Canonical，GCC 与 LLVM 今天已经支持 CFI。
矩阵：三条路线、三张 OS 账单
AI/ML 是 RISC-V 的增长引擎，而几乎所有 AI 负载最终都归结为矩阵运算。但智能传感器端点与训练服务器需要的矩阵机制完全不同，因此 RISC-V 生长出三条不同路线，而不是一个强制的大一统标准：
| 路线 | 全称 | 架构状态 | OS 影响（上下文切换） | 工具链投入（Canonical） |
|---|---|---|---|---|
| VME | Vector Matrix Extension（向量矩阵扩展） | 与标准向量状态相同——不新增 RVV 之外需要保存的寄存器 | 无。不需要任何 OS 改动。 | 相对简单 |
| IME | Integrated Matrix Extension（集成矩阵扩展） | 扩展向量寄存器堆并新增结果寄存器 | 需要 OS 改动。内核上下文切换必须保存/恢复新增寄存器。 | 中等；intrinsics 先行比较现实 |
| AME | Attached Matrix Extension（附加矩阵扩展） | 全新的独立寄存器堆，与向量分离 | 需要 OS 改动。新增状态最多。 | Canonical 原话："a lot of work" |
分水岭在于谁为新状态买单。VME 复用内核已经在做的向量上下文切换，所以 VME 核心对 OS 透明。IME 与 AME 都新增架构状态，内核上下文切换路径必须学会处理新寄存器——在那之前，无视它们的 OS 会在任务切换时静默破坏矩阵状态。
这套分类直接对应本站报道过的硅片：SpacemiT K3 的 A100 AI 核实现的是 IME（据 K3 预印本：IME 1.0 每核私有、IME 2.0 双核共享），这正是 deepin 25 的 K3 移植与 MNN 推理栈都需要进迭时空打过补丁的工具链的原因。而 NVIDIA 在 Hot Chips 2026 公布的 RISC-V 主机 CPU 平台契约，矩阵部分引用的是 VME 系路线。两条路线并不在同一个插槽上竞争——IME 面向集成式 AI CPU，VME/AME 面向规模谱系上的不同位置。
用 sys_riscv_hwprobe() 做运行时探测
因为同一个库可能跑在 VME、IME 或 AME 硅片上——或者都没有——Canonical 强调了 sys_riscv_hwprobe() Linux 系统调用（其早前的自定义指令文章介绍过）：应用向内核查询实现了哪些扩展，在运行时选择正确的代码路径。实践模式是一个库、多份编译产物、运行时选择（代码示例见英文区）。
Canonical 给库作者的结论：把多种实现选择编译进同一个二进制，用 hwprobe 在运行时选择。这与 Arm 用 HWCAP 多年的分发模型相同——只是 RISC-V 把它做成了一等 UAPI。
等待批准期间的树外工作：玄铁
标准批准需要时间，而厂商不会等待。Canonical 点名玄铁（阿里巴巴达摩院）：在 GitHub 上公开推进一个矩阵扩展版本（XUANTIE-RV/riscv-matrix-extension-spec），并在私有 GCC 分支中开发了工具链支持——典型的树外模式：规格公开、工具链厂商先行。我们在 K3 报道中标注过同样的模式；这是做先行者的代价，也是发行版集成总是滞后于芯片发布的原因。
RVA23.1：设计即稳定
profile 小版本修订是 RISC-V 治理哲学体现最明显的地方：小版本修订刻意不包含任何新的强制扩展。这正是 RVA23 软件能多年保持稳定的原因。每次小版本只引入两类可选条目：
| 选项类型 | 含义 | 存在理由 |
|---|---|---|
| 开发选项（Development option） | 预期在未来 profile 中成为强制的前身 | 给软件一个"更软的着陆"——在硬件要求生效之前先完成支持 |
| 扩展选项（Expansion option） | 打算永久保持可选 | 面向实现成本合理、但对所有 profile 用户强制太重的特定应用 |
RVA23.1 新增三个开发选项与两个扩展选项。Canonical 点名了对 Ubuntu（以及所有通用发行版）最重要的三个：
| 扩展 | 作用 | 受益方 |
|---|---|---|
| Ssdbltrap（双重陷入处理） | 覆盖一个狭窄但恶毒的角落：第一个陷入处理器尚处于不可重入状态时发生第二个陷入，可能导致系统崩溃与内存损坏。Ssdbltrap 让机器态或 Hypervisor 态安全接住第二个陷入。 | 内核/Hypervisor 健壮性——减少致命双重故障路径、降低内存损坏风险 |
| Sscfg（S 态计数器委托） | 让 Supervisor（S 态）直接管理和配置性能计数器寄存器，不必绕道机器态固件。 | Linux perf——剖析开销的可测量下降 |
| Ssctr（控制传输记录） | 在硬件中记录分支历史，大幅改善分支剖析——是 RISC-V 上PGO（Profile-Guided Optimization）的使能机制。 | 编译器与剖析器；PGO 需要上游 Linux 内核通过 perf 暴露分支记录缓冲——补丁已存在但尚未被上游接受 |
注意 Ssctr 行里那条诚实的依赖链：扩展只是三脚凳的一条腿——硅片支持、内核管道（perf）、编译器/剖析器集成缺一不可，任何单项单独落地都买不到东西。这正是"开发选项"分级机制存在的意义。
工具链支持小结
| 分组 | Canonical 给出的工具链状态 |
|---|---|
| CFI | GCC 与 LLVM 今天已支持 |
| 矩阵 | 两条路：编译器 intrinsics（类汇编，现在就能用）vs 让编译器自动生成矩阵指令（更难）。VME 相对简单；AME 工作量大。批准期间存在树外厂商工作（玄铁私有 GCC 分支）。 |
| RVA23.1 | 部分特性通过 intrinsics 或 CSR 汇编访问而非代码生成；Ssctr 这类扩展直接对接编译器剖析器 |
对建设者意味着什么
- 现在就可以产出 CFI-ready 的二进制。GCC/LLVM 支持已在；RVA23+ 硬件上指令被忽略，直到核心实现它。开启 Zicfiss 插桩前，先确认设备群真的都是 RVA23+（至少 Zimop 可用）。
- 把矩阵当作每颗芯片的合同，而不是 ISA 上的一个勾选框。问厂商实现的是哪条路线（VME / IME / AME）、内核上下文切换方案是什么、工具链是上游、树外还是 intrinsics-only。
- 库从第一天就按运行时分发设计。
sys_riscv_hwprobe()是受支持的探测机制——把多路径库写进移植计划。 - 关注 RVA23.1 公开评审。Ssdbltrap、Sscfg、Ssctr 对硅片而言采纳成本低（它们正是被设计为鼓励早采纳的开发选项），内核支持落地后立即在健壮性与剖析能力上兑现。
结论
Canonical 的文章难得地没有炒作：RVA23 稳坐公共平台，向后兼容由构造保证，有趣的工作在三条清晰分离的轨道上推进——安全上的 CFI、AI 上的三条矩阵路线、稳定性上的分级小版本。对工程团队的实际启示是：软件可以先动——CFI 工具链今天就有，hwprobe 分发是今天就能用的 UAPI，而开发选项机制存在的意义，正是让今天的可选工作在不破坏任何人二进制的前提下成为明天的强制基线。
Резюме (RU)
Jon Taylor (Canonical) в статье в блоге Ubuntu (15 сентября 2026 г.) описывает развитие RISC-V ISA после RVA23 по трём направлениям. CFI (ратифицирован в 2024 г.): два независимых расширения — Zicfilp (landing pad: косвенный переход мимо посадочной площадки вызывает trap) и Zicfiss (теневой стек: адрес возврата хранится в двух стеках, несовпадение при возврате вызывает trap). На оборудовании RVA23 без реализации инструкции игнорируются; на pre-RVA23 без Zimop инструкции Zicfiss вызывают trap. GCC и LLVM поддерживают CFI уже сегодня. Матричные расширения: VME (состояние как у стандартного вектора — изменений ОС не требуется), IME (расширяет векторный регистровый файл + дополнительные регистры результата — нужны изменения ОС), AME (полностью новый регистровый файл — нужны изменения ОС, много работы). Обнаружение в рантайме — через sys_riscv_hwprobe(). RVA23.1: три development-опции и две expansion-опции; ключевые для дистрибутивов — Ssdbltrap (двойная ловушка), Sscfg (делегирование счётчиков в S-режим, ускоряет perf), Ssctr (записи передачи управления для PGO; патчи ядра ещё не в апстриме). RVA23 остаётся базовой платформой, обратная совместимость сохраняется.
Resumen (ES)
Jon Taylor (Canonical) describe en el blog de Ubuntu (15 de septiembre de 2026) la evolución del ISA RISC-V tras RVA23 en tres frentes. CFI (ratificado en 2024): dos extensiones independientes — Zicfilp (landing pads: saltar a un punto que no sea landing pad provoca trap) y Zicfiss (shadow stack: la dirección de retorno se guarda en dos pilas y una discrepancia provoca trap). En hardware RVA23 sin implementación las instrucciones se ignoran; en pre-RVA23 sin Zimop, las de Zicfiss provocan trap. GCC y LLVM ya soportan CFI. Extensiones de matriz: VME (mismo estado que el vector estándar — sin cambios en el SO), IME (extiende el banco de registros vectorial + registros de resultado adicionales — requiere cambios en el SO), AME (banco de registros completamente nuevo — requiere cambios en el SO, mucho trabajo). Descubrimiento en tiempo de ejecución vía sys_riscv_hwprobe(). RVA23.1: tres development options y dos expansion options; las relevantes para distros son Ssdbltrap (doble trap), Sscfg (delegación de contadores al modo supervisor, mejora perf) y Ssctr (registros de transferencia de control para PGO; los parches del kernel aún no están en upstream). RVA23 sigue siendo la base y la compatibilidad hacia atrás se mantiene.
Résumé (FR)
Jon Taylor (Canonical) décrit sur le blog Ubuntu (15 septembre 2026) l'évolution de l'ISA RISC-V après RVA23 selon trois axes. CFI (ratifié en 2024) : deux extensions indépendantes — Zicfilp (landing pads : un branchement vers un point autre qu'un landing pad déclenche un trap) et Zicfiss (shadow stack : l'adresse de retour est stockée dans deux piles, toute divergence déclenche un trap). Sur du matériel RVA23 sans implémentation, les instructions sont ignorées ; sur du pre-RVA23 sans Zimop, celles de Zicfiss déclenchent un trap. GCC et LLVM prennent déjà en charge CFI. Extensions matricielles : VME (état identique au vecteur standard — aucun changement OS), IME (étend le fichier de registres vectoriel + registres de résultats supplémentaires — modifications OS requises), AME (fichier de registres entièrement nouveau — modifications OS requises, beaucoup de travail). Découverte à l'exécution via sys_riscv_hwprobe(). RVA23.1 : trois development options et deux expansion options ; les plus pertinentes pour les distros : Ssdbltrap (double trap), Sscfg (délégation des compteurs au mode supervisor, accélère perf), Ssctr (control transfer records pour le PGO ; les patchs du noyau ne sont pas encore acceptés en amont). RVA23 reste la plateforme de base et la compatibilité descendante est préservée.
Zusammenfassung (DE)
Jon Taylor (Canonical) beschreibt im Ubuntu-Blog (15. September 2026) die Entwicklung der RISC-V-ISA nach RVA23 in drei Bereichen. CFI (2024 ratifiziert): zwei unabhängige Erweiterungen — Zicfilp (Landing Pads: ein Sprung zu einer Stelle, die kein Landing Pad ist, löst einen Trap aus) und Zicfiss (Shadow Stack: die Rücksprungadresse wird in zwei Stacks gespeichert; eine Diskrepanz löst einen Trap aus). Auf RVA23-Hardware ohne Implementierung werden die Instruktionen ignoriert; auf Pre-RVA23 ohne Zimop lösen Zicfiss-Instruktionen einen Trap aus. GCC und LLVM unterstützen CFI bereits heute. Matrix-Erweiterungen: VME (gleicher Zustand wie Standard-Vector — keine OS-Änderungen nötig), IME (erweitert das Vektor-Registerfile + zusätzliche Ergebnisregister — OS-Änderungen erforderlich), AME (völlig neues Registerfile — OS-Änderungen erforderlich, viel Arbeit). Laufzeiterkennung über sys_riscv_hwprobe(). RVA23.1: drei Development-Optionen und zwei Expansion-Optionen; für Distributionen relevant sind Ssdbltrap (Double Trap Handling), Sscfg (Supervisor Counter Delegation, beschleunigt perf) und Ssctr (Control Transfer Records für PGO; Kernel-Patches noch nicht im Upstream). RVA23 bleibt die Basisplattform, Abwärtskompatibilität bleibt erhalten.
خلاصه (FA)
جن تییلر (Canonical) در وبلاگ Ubuntu (15 سپتامبر 2026) تحول ISA ریسکوی پس از RVA23 را در سه جبهه ترسیم میکند. CFI (تصویبشده 2024): دو پسوند مستقل — Zicfilp (سواحل: پرش به نقطهای غیر از landing pad موجب trap میشود) و Zicfiss (ستک سایه: آدرس برگشت در دو ستک ذخیره میشود، ناهمخوانی موجب trap میشود). در سختافزار RVA23 بدون پیادهسازی، دستوران نادیده گرفته میشوند؏ در pre-RVA23 بدون Zimop موجب trap میشوند. GCC و LLVM امروز CFI را پشتیبانی میکنند. پسوندهای ماتریسی: VME (وضعیت مشابه وکتور استاندارد — بدون تغییرات OS)، IME (توسعه رجیسترهای وکتور + رجیسترهای نتیجه افزودنی — تغییرات OS لازم است)، AME (رجیسترهای کاملاً جدید — تغییرات OS لازم است، کار زیادی میبرد). کشف در زمان اجرا با sys_riscv_hwprobe(). RVA23.1: سه development option و دو expansion optionؠ مهمترینها برای دیستروها: Ssdbltrap (مدیریت trap دوڊم)، Sscfg (برگردان شمارندهها به سطح Supervisor، پرش perf را سریع میکند)، Ssctr (ثبت انتقال کنترل برای PGOؠ پاچهای هسته هنوز به upstream نرفتهاند). RVA23 پایگاه میماند و سازگاری با نسقههای قبلی حفظ میشود.
Sources / 参考来源
- Ubuntu Blog (Canonical) — Evolution of the RISC-V ISA. What next after RVA23? by Jon Taylor (2026-09-15) — primary source for all extension semantics quoted here
- RISC-V Control-Flow Integrity (CFI) specification — official privileged-ISA CFI document
- Announcement of RVA23.1 and RVB23.1 public review — RISC-V isa-dev mailing list
- Ubuntu Blog — How to use RISC-V custom instructions with Ubuntu (sys_riscv_hwprobe() background article)
- Xuantie (Alibaba DAMO) RISC-V matrix extension spec — the out-of-tree matrix work Canonical references
- SiFive 2nd Generation Intelligence Technology Explainer — deeper dive into IME, VME, and AME (linked by Canonical)
- RISC-V Matrix Extensions in 2026: IME, VME and AME, Plus the VME Ratification Dates — our 2026-09-07 article (standards-timeline view of the same three routes)
- SpacemiT K3 Preview Paper — our 2026-09-20 article (K3 A100 cores implement IME 1.0/2.0)
- MNN LLM inference on SpacemiT K3 — our 2026-09-17 article (IME2 matrix extension in production inference)
- NVIDIA: RISC-V as Third Server CPU — our 2026-09-02 article (VME-family matrix route in NVIDIA's platform contract)