一、Linux 主线内核：KVM/riscv 已脱离实验状态
RISC-V 架构的 Linux 上游支持长期以补丁集形式演进，自 Linux 5.x 起 KVM/riscv、AC AIA、IOMMU 等子系统陆续进入主线。2025 年是关键节点：Linux 6.16 移除了 KVM: RISC-V 的 experimental 标签（提交 RISC-V: KVM: Remove experimental tag for RISC-V，随 6.16 拉取请求合入），并引入向量寄存器自测试、VCPU 从用户态复位的能力；Linux 6.17 的 KVM 拉取请求进一步重构 g-stage MMU、为嵌套虚拟化做准备（kvm-riscv-6.17-2 tag 收录于 kvm-riscv/linux 仓库）。两窗口合计已超过 20 项 KVM 相关合入，覆盖 dirty ring、perf kvm stat 中断事件上报、TLB 维护优化等多个方向。
主线内核对硬件能力的支持遵循 ISA、Profile 与平台规范三层结构：底层是基础 ISA 与扩展（RVA23U64、RV64、V、Zvbb、Zicond 等），其上是监管执行环境 Profile（RVA23S64），再之上是 RISC-V Server Platform 等平台规范。需注意 H 扩展（Hypervisor Extension）并非"所有 RVA23 合规硬件强制项"：H 在 RVA23S64 中属于特权模式 optional extension，Profile 进一步通过 Sha（profile-defined 聚合扩展名）将 H 及其配套扩展（Shgatpa 等）作为按选实现时的强制子集；RISC-V Server Platform 规范 RVA_010 把 RVA23S64 列为应用处理器 hart 的 MUST，RVA_020 又在平台层把 Sdext、Sdtrig、Zkr、Ssstrict、Ssccfg、Ssaia 与 Sv48 列为平台必须扩展——这是平台规范的强制项，不可与 Profile 必选项混淆。
中断子系统方面，AIA（Advanced Interrupt Architecture）在传统 PLIC/CLINT 等机制之外，提供了面向多核与虚拟化场景的 APLIC 与 IMSIC 组件；Linux 6.x 系列对 IMSIC 与 APLIC 驱动、IMSIC MSI 框架的支持处于持续合入阶段，AIA 与 PLIC 类机制在不同平台与软件栈中并存而非简单替代关系。时间子系统方面，Sstc（Supervisor-mode Timer Compare）使 S-mode 与 VS-mode 运行环境能够直接使用定时器比较机制，减少传统 SBI/M-mode 路径带来的陷入与软件开销，Linux 上游对 KVM Sstc 的支持自 Linux 6.6 起进入主线。这两类能力与两级地址翻译共同构成 RISC-V 虚拟化栈的基础。
工具链侧，GCC 已支持通过 -march=rva23u64 / -march=rva23s64 等 Profile 选项指定目标 ISA；LLVM/Clang、GCC 与 binutils 在近版本中持续加入对 RVV、Zvbb、Zicond 等扩展的代码生成与汇编支持，但具体子扩展的覆盖程度、自动向量化与调用约定随工具链版本推进，发行版构建所采用的实际默认基线仍需结合 -mcpu / -march 与具体工具链构建配置确认。
二、发行版生态：分层支持与基线迁移
RISC-V 主流 Linux 发行版的支持可分为三档。
主线社区分支。Debian 在 13 (Trixie) 中首次正式将 RISC-V 列为官方架构（riscv64），apt 仓库提供主线二进制包；Arch Linux RISC-V 由社区维护，包管理与工具链兼容主线；Alpine Linux 社区持续提供 RISC-V 架构相关构建与移植支持，但不同版本的镜像与包覆盖范围需要结合具体发行版版本确认。
Ubuntu 与 Fedora。Canonical 在 Ubuntu 25.10 将 RISC-V 内核基线提升至 RVA23S64，26.04 LTS 沿用该基线，面向服务器的发行版二进制将默认使用 RVV 等扩展；24.04 LTS 仍可继续覆盖老旧开发板。Fedora RISC-V 仍属于 non-official architecture：Koji 上已可构建主线软件包，但 RVA23 兼容性、部分工具链与 JVM 生态仍在补齐中。
中国主导的发行版。openEuler 自 23.09 版本起将 RISC-V 列为 Tier-1 架构，是较早完成主线集成并提供 RISC-V 一级架构支持的国内发行版；openEuler 24.03 LTS 同样将 RISC-V 作为发布架构之一，覆盖从嵌入式到服务器端的多种 RISC-V 处理器。龙蜥 Anolis OS 在 23.4 版本中新增 RVA23U64 指令集全面支持：GCC 14.3.0、LLVM/Clang 20.1.8、内核 6.6.102，并支持 Sv32/Sv39/Sv48/Sv57 多级页表、SBI HSM 热插拔、Zabha/Zacas 原子扩展、PMU 性能监控等（Anolis OS 23.4 发行说明）。RISC-V SIG 由多家芯片与操作系统厂商联合维护，构建"同源异构"版本以实现一次开发多架构部署。玄铁 C950是面向高性能计算场景的 RISC-V 处理器 IP，其产品资料可作为观察 RISC-V 多核、一致性互连与向量扩展实现路径的一个产业案例。
三、虚拟化栈：从 H 扩展到 QEMU rvsp-ref
RISC-V 虚拟化建立在 H 扩展之上。两级地址翻译（VS-stage + G-stage）由硬件 MMU 完成：客户机认为自己拥有完整物理内存，hypervisor 通过 hgatp CSR 把客户机物理地址映射到宿主机物理地址，避免完全依赖软件模拟地址转换；实际虚拟化访存开销仍取决于 TLB、缓存、页表遍历、内存工作集以及 KVM/QEMU 实现细节，不能仅依据 ISA 能力推导出"接近原生"的性能。IMSIC 提供 VS-mode 中断文件以支持虚拟中断状态管理，其直接投递路径能够减少传统软件中断注入的开销，但具体硬件中断虚拟化路径与 M-mode 介入频率仍取决于平台 IMSIC 实现与 hypervisor 设计。
QEMU + KVM 是事实标准路径：
xxxxxxxxxx# 验证宿主机内核已加载 KVM 与 AIA 支持ls /dev/kvmgrep -E 'kvm|aia' /boot/config-$(uname -r)# 启动一个 RV64 客户机（需 H 扩展硬件 + 内核含 KVM）qemu-system-riscv64 \ -machine virt,accel=kvm \ -cpu host \ -m 4G -smp 4 \ -kernel guest-kernel \ -drive file=guest.img,format=raw,if=virtio \ -nographic面向 RISC-V Server Platform 规范的参考机 rvsp-ref（hw/riscv/server_platform_ref.c）由社区贡献。需要注意的是，Server Platform 规范规定的能力集合与 QEMU 参考机的当前实现完成度并不等价：v4 版本（2025-11 qemu-riscv 邮件列表）以 EXPERIMENTAL 标识提交，文档明确说明尚未实现 sdext 等调试扩展，将在补齐后按 Server Platform v1.0 完成合规验证。因此 rvsp-ref 更适合作为规范验证与软件适配的参考环境，而不宜直接视为完整服务器平台实现。该参考机可与 edk2-stable202308 配合运行，使用 BRS-I 配方生成 ACPI 表。
xxxxxxxxxx# 在已启用 rvsp-ref 的 QEMU 树上查看与启动参考机./build/qemu-system-riscv64 -M help | grep rvsp./build/qemu-system-riscv64 \ -nographic -m 4G -smp 2 \ -machine rvsp-ref,pflash0=pflash0,pflash1=pflash1RISC-V 虚拟化与机密计算的结合仍在起步阶段：CoVE（Confidential VM Extensions）的规范在持续演进，KVM 端尚未见成熟实现，主流发行版未默认开启相关能力。
四、容器与跨架构构建
RISC-V 容器生态的关键能力是 multi-arch 镜像构建与运行时。Docker buildx 自 19.03 起内置 multi-arch 支持，OCI 镜像清单（manifest list）可包含 rv64 manifest：
xxxxxxxxxx# 创建并使用 buildx 多架构构建器docker buildx create --name multi --usedocker buildx build \ --platform linux/amd64,linux/arm64,linux/riscv64 \ -t myorg/app:multi \ --push .podman 在 4.x 后原生支持 manifest list，build 命令参数与 docker buildx 一致；buildah 提供低层 image 构建 API，可用于定制化 CI。运行端，在支持 RISC-V 的 Linux 环境中，runc、crun 等 OCI runtime 可用于运行针对 riscv64 架构构建的容器镜像；实际可用性仍取决于内核、runtime 版本、seccomp/cgroup 配置以及镜像自身的 ISA 基线，并不能假定"任意 RISC-V 平台 + 任意 runc/crun = 直接运行任意 rv64 镜像"。RISC-V 平台的内存与算力档位差异较大：在 1 GB 内存开发板上运行大型多阶段构建需要降低并行度并使用 BuildKit 缓存后端，否则容易 OOM；这一限制属于具体硬件档位的资源约束，不应外推为 RISC-V 通用性能结论。
发行版的 RISC-V 镜像与多架构清单常通过 docker manifest inspect 验证：
xxxxxxxxxxdocker manifest inspect myorg/app:multi \ | jq '.manifests[] | {platform:.platform, digest:.digest}'五、可用性分层评估
能做什么：mainline Linux 已对 RVA23S64 Profile 涵盖的用户态与监管态强制能力（含 V、Zvbb、Sscofpmf、Svinval、Smstateen 等）持续完善，KVM/riscv 已脱离实验状态，OCI 多架构镜像的构建与分发链路在 Docker buildx、Podman、buildah 三方均可用。openEuler 自 23.09 起就把 RISC-V 列为 Tier-1 架构，24.03 LTS 沿用该定位；Anolis OS / Ubuntu / Debian 在各自定位上提供 RISC-V 发行版支持。
还缺什么：QEMU rvsp-ref 仍标注 EXPERIMENTAL，sdext 等 Server Platform 强制扩展在参考实现中尚未完全到位；满足 Server Platform v1.0 全部系统级要求的公开量产平台仍处于早期阶段，软件栈先行于硬件落地；CoVE 等机密计算能力距离实用仍有相当距离。需要注意的是，Sv48 在 RVA23S64 Profile 中属于可选扩展，是 Server Platform 规范 RVA_020 才将其列为平台层 MUST；Fedora 的 RISC-V 仍属于 non-official architecture，CI 与 nightly 覆盖度低于 x86 与 ARM。对评估者而言，可操作的核对顺序是：先验证 Profile 与平台规范层级（基础 ISA / RVA23S64 / Server Platform）是否匹配，再验证虚拟化栈运行时路径（QEMU + KVM），最后关注上层容器与编排工具的 multi-arch 覆盖度。搭建 RISC-V 开发环境所需的工具链、内核与固件文档等资源，可从资源中心获取。
