6月到8月我们小组的每月技术分享会几乎没停过因为这个夏天RISC-V的更新密度实在太高。从一个追进度的工程师视角看这三个月最值得关注的并不是某一颗芯片的PPT而是risc-v指令集本身开始进入“可工程化落地”的阶段RVA23成为软件生态的实际基线矩阵扩展走进草案冻结流程主线内核和工具链覆盖了更多此前只有x86/ARM才有的性能特性。这篇文章就按我们小组分享会的记录整理适合正在做RISC-V软件移植、评估risc-v指令集服务器或边缘算力可行性或者准备把RISC-V作为下一阶段技术方向的团队参考。内容不按新闻稿的路子写只讲技术动态、规范变化和我们的实测体会。1. 指令集规范的三个关键落点RVA23、矩阵扩展与配置收敛1.1 RVA23从“纸面规范”变成了软件基线过去几年大家聊RISC-V很容易陷入一个迷思指令集扩展太多每个核支持的组合都不一样软件根本没法“一次编写到处运行”。这几个月最大的变化就是RVA23 profile终于不再是PPT上的概念而是被工具链、内核、发行版当作默认参照系。RVA23是什么简单说它把一组扩展固定成一个“应用处理器必须支持”的集合包括基础整数/浮点指令、向量扩展V 1.0、位操作扩展Zba/Zbb/Zbc/Zbs、以及更细粒度的原子操作Zacas等。以前我们做移植时得自己写#ifdef处理“有没有V扩展”“Zbb支不支持”现在只要软件目标声明是RVA23编译器就可以放心地生成依赖这些指令的代码。我这边实测跑了一个基于LLVM 19之后的构建默认target triple带-marchrva23时向量化和位操作相关的优化自动开启性能比之前用裸rv64gc配置有明显提升。最有感觉的是字符串处理库比如memcpy和strlen在支持向量指令的核上差距非常直观。对应用层开发者来说这意味着RISC-V软件生态的碎片化问题正在被规范层面“硬性”收敛。1.2 矩阵扩展进入了“能上桌讨论”的阶段如果说RVA23是存量整合那矩阵扩展就是这季度最让人兴奋的新变量。RISC-V的矩阵指令集目前还处在草案讨论的关键期但形态已经比较清晰它不像GPU那样搞一套完全独立的编程模型而是在向量体系之上增加矩阵寄存器组和张量块指令复用现有的向量寄存器文件降低上下文切换成本。我们小组内部做过一次模拟评估。如果用纯向量指令做8bit整数矩阵乘法在256位向量宽度的实现上需要频繁处理拆分和累加而带矩阵块指令的草案版本一个指令就能完成64×64的8bit块乘累加。对推理场景来说这个差距足以改变NPU替代方案的选择逻辑。虽然matrix扩展的最终冻结还可能调整但方向几乎可以确定边缘AI推理、端侧大模型、甚至部分HPC场景都会受益于这类指令。顺带一提float16和bf16格式在这轮草案里是重点尤其是bf16几乎是LLM推理的标准格式之一。如果你现在要选型RISC-V AI芯片建议关注两个点是否支持矩阵扩展草案的通用形态以及向量扩展是否包含zvfh这类半精度支持。只靠乘加指令硬堆性能的架构未来两年会很难跟上软件生态。1.3 配置漂移问题的收敛与新的“隐性陷阱”规范落地的另一面是配置漂移问题开始缓解但并没有完全消失。RVA23给出的是一个“最低配置”实际SoC往往还会加上自定义扩展。这季度多个主流IP厂商开始提供“RVA23兼容模式”和“自定义扩展模式”两套配置U-Boot和OpenSBI那边也增加了对isa字符串的标准化解析。不过这里有一个新的隐性陷阱部分厂商为了芯片面积会在RVA23基础上砍掉某些非关键扩展比如Zicbopprefetch指令或一些cache管理操作。软件团队如果盲目按照“RVA23一定全支持”来开发可能在特定板卡上遇到非法指令异常。我们小组的做法是做一个启动时探测模块热加载前先校验misa和/proc/cpuinfo里的isa字段不满足要求的直接走降级路径。扩展组主要成员工程影响我们小组的依赖程度向量V, Zvfh, Zvbb多媒体、AI推理、memcpy高位操作Zba, Zbb, Zbc, Zbs内核、基础库、加解密高原子/事务Zacas, Zalrsc并发数据结构、内核同步中缓存管理Zicbom, Zicboz, ZicbopDMA一致性、zero page优化中虚拟化H扩展, 双阶段MMU云原生、容器隔离高服务器组2. 主线内核和用户态软件从“能引导”到“能跑大模型”2.1 内核侧调度、内存和性能事件补课这三个月Linux内核的RISC-V分支提交相当密集给我的整体印象是“补课速度明显加快”。调度层面RISC-V终于跟上了ARM和x86在NUMA拓扑描述上的能力服务器场景多路互联不再是实验特性。内存管理方面大页和内存热插拔的支持也在持续完善虽然还不能说和x86完全对齐但已经能支撑比较正经的数据库类负载。我们自己在一台64核RISC-V服务器上做了p99延迟测试跑的是ClickHouse类的分析查询。坦白说内核调度器默认配置下跨NUMA节点访问的延迟还是比同节点高出一截但通过numactl手动绑定后表现基本达到可接受范围。这说明内核机制已经具备接下来更多是发行版调优的活儿。性能事件子系统也是这季度进步明显的地方。以前RISC-V的perf工具基本只能看cycles和instructions现在硬件计数器的事件类型丰富了很多包括cache miss、分支预测失败、甚至部分实现支持了TLB事件。虽然各家SoC的事件编号映射还需要平台驱动提供但标准框架已经通了。做性能分析的同学可以开始把RISC-V纳入常规benchmark体系不再需要靠time命令猜了。2.2 用户态运行时glibc、编译器与大模型推理的落点用户态生态的成熟程度直接决定RISC-V能不能从“开发板玩具”变成生产力平台。这个季度glibc、LLVM和GCC的RISC-V后端都发布了新的迭代版本几个值得记录的点glibc对RVA23相关的IFUNC函数多版本支持更完善可以在运行时根据CPU特性选择最优实现。这对高性能库意义很大以往需要源码级特判的逻辑可以下沉到动态链接器里。LLVM的RISC-V后端在向量代码生成和寄存器分配上做了不少优化实测编译某个图像缩放算法生成的向量指令数量比GCC少约8%但注意这是特定benchmark的结论换场景可能反转。Rust和Go的RISC-V支持继续推进尤其是Go这季度已经有不少服务端组件可以在RISC-V上直接编译运行。我们用Go写的一个API网关在RISC-V板子上跑了一周稳定性没有问题。大模型推理是我个人最关注的场景。前几个月在RISC-V上跑LLM还主要靠fp32硬扛现在借助bf16 / int8量化库以及V扩展的int8点积指令7B模型在带NPU的开发板上已经能跑出接近实用级的token数。虽然距离x86GPU的体验还有差距但趋势已经非常明确risc-v指令集的向量能力正在成为“端侧小模型”性价比方案的重要组成部分。2.3 虚拟化与容器隔离服务器场景的关键补课虚拟化一直是RISC-V服务器化的短板但这季度有了实质性的进展。KVM的RISC-V支持已经不再是“能启动虚拟机就算成功”的阶段而是在向中断控制器直通、双阶段地址转换、嵌套虚拟化方向靠拢。我们小组在实验室里跑了KVM嵌套虚拟化的早期测试宿主和客户机都是RISC-V客户机里再起一个轻量虚拟化层。虽然性能损耗比较明显但机制能跑通这件事本身就代表架构完整性在提升。对云原生团队来说这意味着未来在RISC-V平台上运行Kubernetes节点时可以依赖标准虚拟化隔离而不是像早期那样靠容器或裸机硬凑。容器侧Docker和containerd的RISC-V支持早已不是问题真正需要关注的是镜像生态。这几个月Debian、Fedora、Ubuntu的RISC-V移植版都在快速增加软件包数量一些常见的数据库、消息队列、监控组件已经能从官方源直接安装。我们的经验是如果要用RISC-V搭建开发环境优先选用这些发行版的原生RISC-V仓库省去交叉编译的脑细胞。3. 芯片与板卡侧的变化多核架构走向“套餐化”3.1 多核SoC的“模板化”趋势这季度发布的RISC-V应用处理器SoC一个明显特征是设计开始“套餐化”标配4到8个乱序执行核心外加向量单元、NPU或DSP再配上PCIe、USB4或CXL等高速接口。这种模板化对软件团队其实是好事意味着我们可以用相对统一的调优策略去面对不同方案。以我们测试过的几款开发板为例它们的性能差异虽然仍受制程和主频影响但指令集特性层面基本都覆盖了V、Zba、Zbb等关键扩展。也就是说软件层面很难再出现“为A板优化的代码在B板上退化为标量”的情况。实话实说两年前我们踩过这种坑一套优化代码在A板跑得很好换到B板因为缺少某个扩展直接性能腰斩。现在这种情况大幅减少。3.2 NPU与DSA到底怎么接总线异构计算的关键细节如果你以为SoC支持RISC-V指令集就等于AI能力那就太天真了。实际决定AI性能的是CPU核心与NPU/DSA之间的数据通路设计。这季度很多方案采用了“CPU负责稀疏控制和数据预处理NPU负责密集矩阵计算”的异构架构而CPU与NPU之间通常走AXI或类NoC总线。我们实测时发现一个有意思的细节即使NPU计算峰值非常高如果CPU侧没有向量指令辅助做数据排布和量化缩放整体吞吐也会被数据搬运卡住。相反支持V扩展的CPU可以在内存侧直接完成int8量化前的浮点转整型、以及per-channel scale的乘加操作把喂给NPU的数据整理好。这样NPU只需要做纯矩阵乘效率高很多。所以选择RISC-V AI方案时别只盯着TOPS数字要问清楚三件事CPU侧是否支持完整的向量指令集NPU驱动是否暴露了零拷贝缓存区接口以及DSA是否支持常见的非标准数据布局。这三个问题直接决定你从模型部署到性能达标要花多长时间。3.3 开发板的可复现性与CI建设这次分享会我们也聊了开发板的工程化问题。RISC-V开发板虽然出货量越来越大但固件、内核、用户态根文件系统之间的版本匹配仍然很折腾人。原因不复杂不同板的OpenSBI、U-Boot和内核补丁可能来自不同的维护分支直接拿上游主线内核去替换板卡厂商内核可能会遇到设备树字段不兼容的问题。我们小组的应对办法是建立一套基于Yocto和Buildroot的CI流程每次更新都会自动构建整个镜像并且在真实板卡上跑冒烟测试。三个月中这个CI抓到两个设备树相关的问题一个是PCIe控制器节点兼容性字符串对不上另一个是中断控制器的cells属性被错误覆盖。这些问题如果靠手工部署可能要折腾一天才能发现CI固化之后基本能在半小时内暴露。4. 工具链和调试体验这个季度让人眼前一亮的小改进4.1 QEMU与仿真器快速验证新扩展的起点在真实芯片还没量产时QEMU几乎是验证risc-v指令集扩展行为的唯一高效手段。这季度QEMU的表现相当靠谱对RVA23里多数扩展的模拟已经比较完善我们用它跑过完整的Linux启动和基础的向量基准测试。启动一个带多种扩展的RISC-V虚拟机比想象中简单qemu-system-riscv64 \ -machine virt \ -cpu rv64,von,zbaon,zbbon,zbcon,zbson \ -smp 8 \ -m 16G \ -kernel vmlinux \ -initrd initrd.img \ -append root/dev/ram consolettyS0注意-cpu参数里显式打开扩展不同版本的QEMU默认支持的扩展组合不一样。如果遇到“非法指令”错误先用这个最小参数组合确认基础环境再逐步增加扩展排查起来会快很多。4.2 栈回溯与调试信息的三个痛点这半年调试RISC-V程序最折磨人的几个问题集中在栈回溯上缺少frame pointer的优化代码、CFI指令生成不完整、以及GDB对向量寄存器组的可视化支持不够直观。这季度工具链做了不少改进但远说不上完美。我在一次排查段错误时发现编译器在-O2下生成的.eh_frame竟然不完整导致GDB顺着栈回溯时在某个函数边界直接断掉。当时的临时方案是给那个模块单独加上-fno-omit-frame-pointer重新编译问题立刻消失。长期来看还是要依赖LLVM/GCC维护者持续完善CFI指令。如果你也常做crash分析建议在RISC-V的工具链版本选择上保持激进尽量用较新的发布版很多栈回溯的坑都是在新版本里悄悄修复的。4.3 性能分析工具的“可依赖度”提升过去用perf profiling RISC-V程序总觉得像蒙着眼睛开车。这季度随着perf event支持完善局面改善很多。我在同一个程序上同时跑了perf stat和perf record能拿到cache miss、branch miss的数据定位到某个热函数里分支预测失败率偏高进一步发现是哈希表链式遍历导致的随机访问。不过要提醒的是不同SoC实现的PMU事件映射还是有差异。最稳妥的做法是先在目标板上跑一遍perf list确认板级驱动导出了哪些事件再决定分析方案。不要拿A板上的perf数据直接指导B板的优化决策至少我踩过这个坑。5. 安全与形式化验证新闻最少但含金量最高的赛道5.1 指针认证与内存标记的落地路线安全扩展在RISC-V生态里一直属于“听得到脚步声、看不到人”的状态。这几个月指针认证Pointer Authentication和影子栈机制逐步从草案走向公开讨论部分IP厂商宣布会在下一代核里集成相关能力。指针认证的思路很直接用密钥对返回地址或函数指针做签名在跳转前验证利用额外的高位bit存放MAC值防止栈溢出或函数指针篡改攻击。这跟ARM的PAC站在同一技术路线上。软件侧内核的ROP防护机制已经预留了相关支持框架等硬件铺开后可以直接启用。我们内部的判断是未来两年RISC-V服务器芯片会把安全问题当成标配竞争点而不只是可选的加分项。如果你做的是云基础设施方向建议提前在软件架构里把“启用指针认证”作为一个编译选项预留好不要等硬件到位再回头改软件ABI。5.2 形式化验证工具链开始进入工程实践严格来说形式化验证不算新闻这季度真正有意思的是相关工具链开始从学术论文走向工程流水线。RISC-V规范本身用SAIL语言描述这就让以规范为参考模型的形式化验证成为可能。利用这类方法可以形式化验证一个硬件实现是否满足规范要求或者验证编译器的指令选择是否正确。我们小组自己也做了一次小规模的尝试用riscv-formal配合Yosys对一个极简CPU核做断言检查成功抓到了一个特定条件下指令回写阶段的竞态问题。虽然这种级别的验证对于复杂处理器还不够直接用但作为IP选型时的“体检”手段性价比已经超过人工代码审查。5.3 合规测试与配置隔离商业落地前的最后一公里RISC-V指令集虽然开放但“开放”不等于“免费加随意标识”。基金会这几个月明显加强了对RVA23配置的合规测试工作芯片若要打上RVA23兼容的旗号需要跑通一套官方或规范的测试集。我们拿到早期测试列表后发现除了指令行为本身测试还覆盖了CSR寄存器、中断异常行为和虚拟化相关接口这比单纯跑benchmark严格得多。对下游用户来说合规测试是件好事相当于给“支持xx扩展”这个说法提供了一个可信度基准。但也要留意合规测试本身可能成为商业壁垒的一部分不是所有厂商都能轻松通过。在选型时尽可能选择明确公布合规状态的方案减少后续法律和兼容性层面的风险。6. 小组内部的三个经验与后续三个月关注重点6.1 实测如何快速验证一个新扩展是否可用每次看到新的risc-v指令集扩展草案我们的第一反应不是读文档而是先跑一个最小示例验证工具链是否支持。方法很简单写一个内联汇编调用目标指令用-march指定待测扩展编译然后在QEMU或者真机上运行看是否产生非法指令异常。例如验证Zacas原子比较交换扩展是否被支持可以先写一个简单的原子操作调用再检查编译和运行结果#include stdio.h #include stdint.h static inline long cas_64(volatile long *ptr, long old, long new) { long res; __asm__ __volatile__ ( amocas.d.aqrl %0, %2, (%3)\n : r(res) : 0(old), r(new), r(ptr) : memory); return res; } int main(void) { long x 10; long prev cas_64(x, 10, 42); printf(prev%ld now%ld\n, prev, x); return 0; }这类小实验比翻几百页规范文档直观得多强烈建议拿到新扩展的第一时间就动手跑一下。运行时会拿到真实结果也方便后续给团队分享时讲得具体。6.2 从邮件列表和补丁流里提取信息的技巧RISC-V生态的信息源非常分散但真正值得跟的只有几路Linux内核的linux-riscv邮件列表、LLVM社区关于RISC-V后端的改造、以及RISC-V基金会各技术任务组的GitHub仓库。邮件列表适合看趋势补丁流适合看实现细节而规范仓库则适合做深度参考。我个人的习惯是每个周末快速扫一遍linux-riscv邮件列表的标题把跟RVA23、向量扩展、虚拟化、安全相关的主题单独记录下来。三个月下来基本上能形成一张很清晰的“各路技术方向都在忙什么”的地图。团队里如果有人愿意承担这个角色整体信息获取效率会提高很多。6.3 后续三个月建议关注的主题从当前节奏推演接下来一段时间有几个点值得盯紧一是矩阵扩展草案的正式投票与可能的更新这会直接影响AI推理软件栈的选型二是内核虚拟化路线在中断控制器和直通场景上的进展服务端团队可以据此做基础设施规划三是GCC与LLVM在向量代码生成质量上的差距变化毕竟工具链的优化水平决定了应用性能的上限。我个人还会特别关注低功耗嵌入式方向的扩展动态尤其是与安全和隔离相关的部分。RISC-V的价值不只是高性能它在从极简MCU到服务器的全谱系覆盖能力才是最吸引人的地方。把这几个月规范、内核、芯片、工具链的变化放在一起看整个生态的成熟速度确实比很多人预期的要快。