技术指南：从扩展支持到内核配置——RISC-V 扩展在工具链、内核与 libc 中的落地链路

一、引言

前三篇依次讨论了三代原子能力与锁实现：LR/SC 到 qspinlock、AMO 宽度扩展到 Zabha/Zacas、自旋锁到 rt_mutex 与 PREEMPT_RT。三者共享同一个前提：目标平台的硬件扩展能被工具链编码、被内核探测、被正确启用。该前提在前三篇中只作为结论出现——"工具链不支持的扩展，内核也不会使用"——本文将其展开为一条可逐层核对的链路，并给出每层的失效判据。

二、三层的职责划分

扩展从规范到运行时要穿过三层，各层职责不同。规范层定义扩展语义与 Profile 中的地位，回答"能否主张该能力"；工具链层决定能否把扩展编码进指令流，回答"能否编译出来"；内核与运行库层决定最终是否使用该能力，回答"是否真的执行到对应指令"。

三层是必要条件串联，而非叠加优化。规范已批准但工具链不支持的扩展，内核配置项直接不可选；工具链支持但设备树未声明、或内核未登记该扩展的，运行时按不支持处理。多数情况下的最终表现是静默回退到通用路径，不产生编译错误，也不产生运行时告警——这是这条链路最容易误判的地方。

规范层内部还需区分两类条款：Profile 中的强制能力是所有声明符合该 Profile 的实现都必须具备的基线，扩展选项则由实现自行取舍。Profile 名相同不代表可用扩展集合相同，工具链支持全部扩展也不代表目标平台具备——软件侧的判断依据只能是设备树或 ACPI 的实际声明。三层之间的失配通常出现在只升级一侧的场合：更换工具链而内核版本未同步，或更换内核而设备树未同步。

三、编译期：-march 与 .option arch 的粒度

-march 的作用域是整个编译单元。内核需要的粒度更细：单个函数或一段内联汇编使用扩展指令，其余代码保持基线编码，否则整个内核镜像的 ISA 基线会被抬高。这一需求落在汇编器的 .option arch 上——内核 Kconfig 中的 AS_HAS_OPTION_ARCH 即用于确认该能力。

以 Zabha 为例，内核的门控链条可以逐行核对：TOOLCHAIN_HAS_ZABHA 用 $(cc-option,-mabi=lp64 -march=rv64ima_zabha) 在配置阶段探测工具链能否编码该扩展，并要求汇编器支持 .option arch；RISCV_ISA_ZABHA 依赖前者与 RISCV_ALTERNATIVE，默认开启；arch/riscv/Makefile 仅在 TOOLCHAIN_HAS_* 为真时把 zabha、zacas 追加进 -march。Zacas 采用同一套结构，二者可以独立开启。LLVM 侧还牵涉实验扩展开关与版本化扩展名（如 _zabha1p0），即扩展名需与版本号一起与工具链口径对齐。补丁系列的说明直接点明后果：工具链缺少 Zacas 支持时，Zabha 提供的 CAS 指令不会被使用。

由此可以读出内核实际使用扩展的判据：编译期选项已开启，且运行期探测确认扩展存在，两个条件同时成立才走到扩展指令；任一条件不成立即进入回退路径，回退在源码层面是显式的分支，在运行结果上则完全静默。

四、内核期：设备树声明与运行期探测

硬件能力的声明来源有两处：设备树与 ACPI 表。二者的 ISA 声明语义由同一来源构造并绑定，解析结果一致。早期的 riscv,isa 字符串已被弃用（commit aeb71e42caae，"dt-bindings: riscv: deprecate riscv,isa"），原因是其语义随 ISA 手册修订漂移——例如 i 在历史上隐含 zicsr_zifencei，不同时期的实现者对此理解不一。替代方案是两个属性：riscv,isa-base 给出基 ISA，riscv,isa-extensions 以布尔列表逐项声明扩展，每项的含义固定在 extensions.yaml 中。该文件同时是一条流程要求：新增扩展若要进入内核探测清单，需先在 binding 中登记。

内核在启动早期解析设备树与 ACPI，构建 hart 的扩展位图，运行期以 riscv_has_extension_unlikely() 一类接口查询；热路径上由 alternatives 在启动阶段把 nop 替换为跳转，避免逐次判断。该机制把判断成本从热路径移到启动阶段，代价是内核镜像中同时保留两条路径的代码。Zabha 的 cmpxchg8/16 实现即两路并存：运行期确认扩展可用时走 amocas 路径，否则回退到掩码化的 LR/SC 序列。设备树声明与内核版本不匹配时（内核未登记该扩展），探测结果按不支持处理，回退路径同样不报错。

五、用户态：hwprobe 与 libc 分发

用户态早期的能力查询手段是 HWCAP：AT_HWCAP 中的 COMPAT_HWCAP_ISA_V 位只能说明向量扩展存在，不区分版本，也覆盖不到多字母扩展。Linux 6.4 引入 riscv_hwprobe 系统调用（__NR_riscv_hwprobe 为 258），可查询处理器厂商与型号标识、CPUPERF_0（非对齐访问的处理方式与代价）与 IMA_EXT_0（扩展位）。相对 HWCAP 的优势有四：位宽可扩展、支持多字母扩展名、位的含义有明确版本定义、可返回实现级性能信息。CPUPERF_0 一类信息对运行期分支有直接价值，例如 memcpy 在非对齐访问代价高的实现上需选择不同的数据组织方式。

使用该接口有两处语义需要留意。其一，6.3 及更早的内核返回 ENOSYS，此时可直接推断相关扩展均不被内核支持，无需重试；扩展位本身在 6.5 才补齐，故 6.4 内核上的查询结果并不完整。其二，libc 封装有时间差：glibc 2.40 起提供 __riscv_hwprobe，更早版本需自行发起系统调用并自带常量定义。多版本分发当前依赖按编译单元分离编译加运行期选择（glibc 的 ifunc 即此模式），单一编译单元内的 target_clones 在该优化指南成文时尚未支持 RISC-V 目标。

工具链、内核、libc 三者版本不齐时，硬件能力会被逐层折损。适配工作中先对齐这条链的版本基线比先写优化代码更有效；对于需要在同一二进制中覆盖多代平台的发行版，这条链的每一层都需给出明确的最低版本要求。厂商软件栈公开的组成信息可作起点，例如玄铁软件与工具页列出的工具链、SDK 与运行环境范围。

六、坑位与关键结论

坑位：

1. 工具链门控优先于硬件事实。cc-option 探测失败时 RISCV_ISA_ZABHA 不可选，内核退回掩码 LR/SC 路径，与芯片是否支持该扩展无关。

1. .option arch 是按函数启用扩展的前提。汇编器不支持时相关 Kconfig 直接不可用，升级 binutils 或 LLVM 的收益常在此处。

1. 多字母扩展可能带版本后缀（如 _zabha1p0），扩展名与版本号需与工具链文档对齐；LLVM 侧的实验扩展开关会直接决定能否编码。

1. 设备树须与内核匹配。新扩展需已在 extensions.yaml 登记并被内核解析，否则按不支持处理，且不给任何提示。

1. riscv_hwprobe 的 ENOSYS 携带信息：6.3 及更早内核下应直接判定相关扩展不支持，不应作为临时故障重试。

1. HWCAP 只表达存在性，不能用于版本相关分支；向量扩展版本（1.0 与 0.7.1）的判定需依赖其它手段。

关键结论：RISC-V 扩展的落地是一条三层对齐链——规范定义能力、工具链编码能力、内核与 libc 探测能力。任一层缺失都会静默回退到兼容路径，而回退不产生报错，因此"硬件标称支持"与"软件实际使用"之间需要逐层验证。前三篇讨论的自旋锁、子字原子与睡眠锁性能差异，最终取决于这条链在目标平台上是否完整闭合。