RISC-V 64 虚拟化技术调研：机制、Linux/Android/RTOS 的路线差异与平台选型

版本历史

术语与缩略语

可靠性标记

【C】 表示规范原文、官方文档或一手资料可直接核查的事实，不代表本报告已实测；【C*】 表示稳定的通用工程原理；【S】 表示厂商或组织的单方声明，未交叉验证；【P】 表示分析、估算、建议或条件性情景；【?】 表示本次证据不足。正文中的"判断""建议""估算"同样限定结论性质。

版本规则：除明确注明其他版本外，RISC-V 架构结论以当前 ratified 规范（H 扩展 1.0、RVA23 v1.0）为准；本文档检索的 Linux 内核文档对应 7.3.0-rc5 系列页面；产品能力以厂商公开页面为准，不把"宣称支持"等同于"通过认证或量产验证"。

1. 核心判断（TL;DR）

• 【C】虚拟化的本质是"用一层特权软件换取隔离与资源整合"，三种系统把同一套机制用于不同目标。Linux 用它做资源池化与容器底座（KVM、Xen、Jailhouse、namespaces/cgroups）；Android 用它做安全隔离（AVF 以 pKVM 为参考 hypervisor，向应用提供 Protected VM）；RTOS 与车规用它做混合关键性整合（QNX Hypervisor、PikeOS、INTEGRITY Multivisor 以及 Bao 等静态分区方案）。[S09][S10][S12][S13][S18][S20][S21][S22][S25][S26]
• 【C】RISC-V 64 的硬件虚拟化由 H 扩展定义，且规范故意保留了可选空间。两阶段翻译（VS-stage + G-stage）、VS/VU 模式、hedeleg/hideleg 中断与异常委托是第一梯队机制；但 VMID 位数"UNSPECIFIED、可以为零"，GEILEN 与 hgeip/hgeie 的实现位数同样"UNSPECIFIED"，意味着"有 H 扩展"不等于"能做完整虚拟化"，选型必须逐项核对。[S01] RVA22 起 H 进入 profile，RVA23 通过 Sha（augmented hypervisor extension）把 H 及其配套（Ssstateen、Shcounterenw 等）列为强制，Sstc 也从可选转为必选。[S02][S03]
• 【C】软件栈已经分化出三条可用的 RV64 路径，成熟度各不相同。KVM RISC-V 自 Linux 5.16 起进入主线并持续演进（5.19 Sv57x4、6.1 Svinval、6.3 性能监控、6.4 AIA CSR 虚拟化、6.10 SBI v2.0 PMU 与客体采样）；Xen RISC-V 仍在下游分支开发，2026 年 9 月首次在真实硬件（HiFive Premier P550）上启动客体域，尚未上游；Bao、Xvisor、Jailhouse 提供面向嵌入式的静态分区或轻量虚拟化。[S14][S15][S16][S17][S28][S29][S30][S25][S26][S27]
• 【S】国内厂商已把"完整虚拟化"作为新一代 RV64 核的卖点，但证据等级是厂商声明。SpacemiT X100 宣称"首款支持完整虚拟化的 RISC-V 处理器核"，支持 RV Hypervisor 1.0、AIA 与 IOMMU 扩展，覆盖 CPU、内存、中断、IO 四类硬件虚拟化能力；阿里玄铁 C950 宣称支持 RVA23.1 全部标配与可选扩展并原生支持 CoVE 机密计算，玄铁 Linux SDK 内含 Hypervisor 虚拟化子系统；香山昆明湖在 QEMU 机型文档中标注为 RV64GCBSUHV（含 H 与 V）。[S34][S35][S36][S33][S37]
• 【P】选型建议：先核对芯片的 H/AIA/IOMMU 实现完备性，再按场景选路线。需要动态多租户用 KVM（Linux 宿主）或等待 Xen 上游成熟；车载/工业的混合关键性优先"认证 hypervisor + 静态分区"（QNX Hypervisor for Safety、PikeOS、INTEGRITY Multivisor、Bao）；开发验证可用 QEMU（RISC-V virt 已默认开启 H 扩展）。容器与虚拟化解决不同问题，不要互相替代。[S12][S13][S20][S21][S22][S25][S28][S32]

2. 问题、范围与方法

2.1 调研问题与边界

本报告回答四个问题。第一，虚拟化的机制边界在哪里：哪些是硬件职责（特权级、两阶段翻译、中断与 DMA 隔离），哪些是软件职责（调度、设备模型、客体支持）。第二，Linux、Android、RTOS 面对同一套机制时的路线差异：谁是宿主、谁是客体、什么时候刻意不用虚拟化。第三，RISC-V 64 上"能跑虚拟化"需要哪些条件：H 扩展及其可选项、AIA 的 guest interrupt file、IOMMU、Sstc、CoVE，以及 KVM/Xen/Bao 等软件栈的就绪度。第四，面向 2026 年的平台选型与验收口径。

调研截点为 2026-09-29。证据以 RISC-V 规范（H 扩展 1.0、RVA23 v1.0、AIA、IOMMU、AP-TEE/CoVE、Sstc）、Linux 内核文档与版本日志、Android AVF 官方文档、厂商公开产品页与 2026 年内的公开报道为准。排除未公开实现细节、商务条款、真实硬件基准测试与认证机构评估。本报告不执行第三方仓库代码、不安装生产依赖、不进行目标板实测。

2.2 证据分级与判读口径

本报告把"规范声明"与"产品能力"分开判读。规范层面：docs.riscv.org 的 ratified 规范与 GitHub 上 RISC-V 官方技术组仓库属于一手依据；厂商页面（QNX、SYSGO、Green Hills、SpacemiT、玄铁）属于单方声明，标注【S】。版本层面：KVM RISC-V 的能力按 Linux 内核版本切分，版本号以 kernelnewbies 变更摘要与上游仓库为准；Xen RISC-V 明确区分"上游"与"下游分支"，不把博客演示等同于主线可用。网络层面：个别站点（source.android.com、phoronix.com）在本次研究期间从采集环境访问不稳定，其内容以官方页面快照与权威检索结果为交叉参考，并在来源台账中如实标注。

一个必须坚持的判读习惯是："体系结构允许"与"硅片实现"是两个判断。H 扩展规范允许 VMID 与 GEILEN 为零；RVA23 虽然强制 Sha，但通过 RVA23 认证的具体芯片清单需要以厂商规格书为准。同理，"支持 KVM"与"能稳定跑多租户"之间隔着 AIA、IOMMU、固件与驱动的完整度。

3. 全球技术基线

3.1 虚拟化机制与术语基线

虚拟化的工程定义可以拆成四件事：特权分层、地址隔离、中断注入、设备模型。特权分层把"管理虚拟机的代码"放在比操作系统更高的特权级；地址隔离保证客体看到的"物理地址"与真实机器地址之间隔着第二层页表；中断注入把外部事件安全地送进客体；设备模型决定客体如何访问磁盘、网络与外设。

按实现位置，hypervisor 分为 Type-1（直接运行在裸机上，如 KVM、Xen、Bao）与 Type-2（寄宿在宿主操作系统上）。按客体的配合程度，分为全虚拟化（客体无需修改）与半虚拟化（客体使用约定的驱动与接口，如 virtio）。Linux 内核文档把 KVM、UML、paravirt_ops、ACRN、SEV/TDX 等内容统一收录在虚拟化章节，KVM API 的中心是 /dev/kvm 与一组 ioctl：打开 /dev/kvm 得到子系统句柄，KVM_CREATE_VM 创建虚拟机文件描述符，KVM_CREATE_VCPU 或 KVM_CREATE_DEVICE 创建虚拟 CPU 与设备。[S09][S10]

设备虚拟化的标准答案是 virtio。OASIS 的 VIRTIO 1.2 规范（Committee Specification 01，2022-07-01）开宗明义："虚拟设备对客体而言看起来像物理设备"，其目的是让"虚拟环境与客体拥有直接、高效、标准且可扩展的虚拟设备机制，而不是每个环境或每个操作系统各配一套专属机制"。设备直通（如 VFIO）则相反：让客体直接访问物理设备以获得接近原生的性能，但必须由 IOMMU 保证 DMA 只能触及该客体的内存。[S31]

容器不是虚拟化：namespaces(7) 的定义是"把全局系统资源包装进抽象层，使命名空间内的进程以为自己拥有独立实例"，其用途之一是"实现容器"；cgroup v2 负责把任务聚合/划分成层级组以施加资源控制。容器共享同一个内核，因此没有指令级隔离，也无法运行异构内核的客体——这与虚拟机解决的"隔离 + 异构"问题正交，两者常配合而不是互相替代。[S12][S13]

从确定性视角看，虚拟化的每一层都会引入代价：特权级切换与陷阱处理增加抖动，两阶段翻译增加 TLB 压力与页表遍历次数，虚拟设备模型把一次 I/O 变成多次陷阱或共享内存握手，中断注入需要经过 hypervisor 的转发路径。这解释了为什么实时系统要么拒绝虚拟化，要么选择"静态分区 + 最小 hypervisor"——把不确定性压到配置期。[S20][S22][S25]

3.2 Linux 的虚拟化路线：宿主、客体与容器三栖

Linux 的虚拟化路线可以概括为"内核内 hypervisor + 泛化宿主"。KVM 把 hypervisor 做进内核：虚拟 CPU 就是一个可被调度的任务，宿主的调度器、内存管理、电源管理直接复用。这套设计的直接结果是 Linux 同时扮演三个角色：宿主（用 KVM 或作为 Xen Dom0 承载其他系统）、客体（自己也能被别的 hypervisor 或云平台运行）、容器底座（用 namespaces 与 cgroup 代替轻量隔离）。[S09][S10][S12][S13]

内核文档还显示了 Linux 虚拟化的深度铺开：x86 侧有嵌套虚拟机、TIMEOUT、SEV/TDX 机密计算；ARM64 侧有 pKVM——以 kvm-arm.mode=protected 启动时，pKVM 在 EL2 安装主机身份映射的 stage-2 页表，把宿主内核降级为被 stage-2 隔离的第一个域，用"受保护的 KVM"支撑更小的可信计算基。pKVM 被内核文档明确标注为"实验性开发特性，可能随新隔离特性引入而破坏兼容"。[S11]

Type-1 侧，Xen 以 Dom0 模型把 Linux 作为特权域来托管管理栈；嵌入式和车载方向的 Jailhouse 则是"基于 Linux 的静态分区 hypervisor"，用最小的代码量把 CPU、内存与外设按核/按区域切给不同负载，换取强隔离与低开销。[S26][S29] 云侧 ACRN、机密计算专用组件等也在内核文档中占位。[S09]

RISC-V 方面，KVM RISC-V 是 Linux 虚拟化在 RV64 的第一主力：自 Linux 5.16 进入主线（含初始 KVM 支持）[S14] 后持续补全——5.19 支持 Sv57x4 与 HFENCE 改进 [S08]，6.4 实现 AIA CSR 虚拟化 [S15]，6.10 支持 SBI v2.0 PMU 改进与客体性能采样 [S16]，上游代码库由 kvm-riscv/linux 持续维护 [S17]

3.3 Android 的虚拟化路线：把"隔离"做成平台能力

Android 的虚拟化不是从"服务器整合"出发，而是从"安全隔离"出发。Android Virtualization Framework（AVF）的官方架构文档给出的骨架是：pKVM 作为参考 hypervisor（"built upon the Linux KVM hypervisor"），crosvm 作为 VMM（"runs virtual machines through Linux's KVM interface"）负责虚拟机生命周期与设备模拟；AVF 区分普通虚拟机与受保护虚拟机，受保护实例通过第二层翻译的页表所有权元数据与 IOMMU 防 DMA 实现"宿主也无法窥探"的隔离；客体与宿主之间通过 hypercall、内存访问陷阱区与半虚拟化 virtio 队列通信。[S18]

这套设计的官方用例是把高风险或高敏感代码从主 Android 移进隔离环境——隔离编译、密钥与认证类服务、以及第三方操作系统（如 Linux 终端环境）。高通在自家芯片上提供了另一个 hypervisor 选项：Qualcomm 开发者博客明确写道，"pKVM 是 AVF 的参考 hypervisor"，而高通在自研芯片组上"添加了以 Gunyah Hypervisor 支撑 AVF 的能力"，供应用开发者把负载移入受保护虚拟机。[S19][S18]

Android 与 Linux 的关系是"复用 + 增量"：AVF 建立在 Linux 内核、KVM 接口与 IOMMU 之上，Android 自己定义的是 API、生命周期与证明链。对车机（AAOS）而言，更常见的形态反过来——Android 作为 Type-1 认证 hypervisor 之上的客体：QNX Hypervisor 的产品页明确把"用你选择的 OS 运行你的应用与服务"写成价值点，并列出了 Android 与 Linux 作为客体操作系统的场景。[S20] 需要指出的是，AVF/pKVM 当前的一手证据集中在 ARM64 与 x86_64（测试用途）；RISC-V 64 上 AVF 的可用性本次未取得一手证据【?】，不应默认"Android 虚拟化能力随 AOSP 一起就绪"。[S18]

3.4 RTOS 与车规的虚拟化路线：减法的艺术

RTOS 世界对虚拟化的态度与通用操作系统相反：不是"给内核增加能力"，而是"把不需要的东西从关键路径里剥出去"。这体现为三个谱系。

认证超visor 与分离内核。 QNX Hypervisor for Safety 建立在 QNX OS for Safety 之上，承诺确定性调度、有界延迟与强域隔离，并明确其用途是"防止客体操作系统把系统中的安全关键组件拖垮"，通过向设计安全状态的转换实现故障遏制，为 ISO 26262、IEC 61508、IEC 62304 的安全论证提供架构支撑。[S20] SYSGO 的 PikeOS 以 "RTOS & Hypervisor" 一体形态提供安全与安保认证套件（CertKits），并明确将 RISC-V 列为下一代架构方向。[S21] Green Hills 的 INTEGRITY Multivisor 自述为"经过认证的安全虚拟化架构"，可在多核 SoC 上"同时运行一个或多个客体操作系统与生命/任务关键功能"，其分离内核谱系列举了 ISO 26262 ASIL D、DO-178B Level A、EN 50128 SWSIL 4、IEC 61508 SIL3 等资质。[S22] 航空领域的 ARINC 653 则用标准化的时间与空间分区定义"分区化操作系统环境"：每个分区相互隔离，任何一个分区的故障不得影响其他分区。[S23]

开源静态分区。 Bao 的定位是"轻量级静态分区 hypervisor"，强调"强隔离与实时保证"，面向混合关键性系统，聚焦故障遏制与实时行为，其仓库同时维护 ARM 与 RISC-V 构建流水线。[S25] Jailhouse 以"基于 Linux 的分区 hypervisor"为定位，用最小代码实现 CPU 与设备的静态划分。[S26] Xvisor 是"可扩展、通用、轻量的 Type-1 hypervisor"，覆盖 ARMv7a-ve、ARMv8a、x86_64 与 RISC-V 等平台。[S27] 静态分区的共同点是：资源在配置期固化，运行期几乎不动页表与调度决策，代价是利用率与灵活性，收益是可论证的确定性与隔离。

RTOS 作为客体。 反向路径同样存在且成熟：Zephyr 的 xenvm 板级方案允许"在任意支持 ARM 虚拟化扩展的 ARMv8 板上以 Xen 客体运行 Zephyr"，为嵌入式安全场景提供"小 RTOS + 大 Linux"的共存形态。[S24] 一般规律是：RTOS 很少做宿主，更多做客体或被静态分区取代——因为把通用虚拟化的动态性引入实时内核，等于把不确定性重新引回关键路径【P】。

3.5 三者对照：目标、宿主与代价

把三条路线放进同一张表，差异的根源是"虚拟化为谁服务"：Linux 服务资源池化，Android 服务安全隔离，RTOS/车规服务混合关键性整合。

图 1：Linux、Android 与 RTOS 的虚拟化路线对照（Linux 列：容器—KVM 内核内 hypervisor—Xen Dom0—客体/云；Android 列：应用—AVF 框架—pKVM 或 Gunyah—crosvm 设备模型—受保护虚拟机；RTOS 列：关键任务—认证 hypervisor 或静态分区—分区/客体—硬件）。来源为 Linux 内核文档、Android AVF 文档、QNX/SYSGO/GHS 产品资料与 Bao 项目文档归纳；为架构示意，不表示具体产品的模块划分或性能数值。[S09][S18][S20][S21][S22][S25]

三者不是同一条光谱上的远近，而是三种不同的取舍方向：Linux 用通用生态换隔离与运维效率，Android 把隔离做成平台服务，RTOS 用减法换确定性；三列的边界与代价关系见图 1。

三条路线里，"确定性从哪里来"仍是划分阵营的那条线：Linux 把不确定性收敛为可调接口（调度类、抢占模型、绑核与直通），Android 用虚拟化把不确定性隔离在受保护边界之外，RTOS/车规用静态配置在源头上消灭不确定性。对 RISC-V 64 的启示是直接的：想在 RV64 上做哪一类虚拟化，取决于你需要的是"动态多租户"（对 Linux/KVM 的成熟度要求最高）、"安全隔离"（对 TEE 与 IOMMU 的完整度要求最高），还是"确定性整合"（对静态分区与认证证据链的要求最高）。[S10][S18][S20][S25]

3.6 RISC-V 64 虚拟化机制：H 扩展与配套扩展

RISC-V 的硬件虚拟化由 H 扩展（Hypervisor Extension，RVH，1.0 已 ratified）定义，它的核心是三个设计决定。

第一，两级地址翻译。 客户机虚拟地址先经 VS-stage 翻译（由 vsatp/satp 控制）得到客户机物理地址，再经 G-stage 翻译（由 hgatp 控制）得到机器物理地址；规范原文把两阶段称为 "VS-stage and G-stage translation"。为容纳更大的客户机物理空间，页表模式扩展为 Sv39x4 与 Sv48x4：Sv39x4 要求"地址位 63:41 必须全为零，否则触发 guest-page-fault 异常"，Sv48x4 对应 63:50。[S01]

第二，VS/VU 特权模式。 V=1 时 hart 处于虚拟监督模式（VS-mode）或虚拟用户模式（VU-mode）；特权序为 HS-mode 高于 VS-mode、VS-mode 高于 VU-mode。中断与异常的委托由 hedeleg/hideleg 控制，陷阱诊断信息经 htval/htinst 提供；而在 V=1 时执行虚拟化访存指令（HLV/HLVX/HSV）会触发 virtual-instruction 异常，防止嵌套。[S01]

第三，规范刻意保留的可选空间。 规范明确"当 HSXLEN=64 时实现不必支持所有已定义的 MODE 设置"；"VMID 位数是 UNSPECIFIED，可以为零"；"hgeip 与 hgeie 中实现的位数是 UNSPECIFIED，可以为零"。这三句话的工程含义是：H 扩展是一个能力框架，不是一份验收清单——一个"支持 H"的芯片可能没有虚拟机标识符 TLB 标签、也可能完全不做客体外中断。[S01]

配套扩展补齐了 H 之外的拼图。中断：AIA 把外部中断从 PLIC 时代推进到 IMSIC/APLIC；规范原文指出"当 hart 也实现 H 扩展时，IMSIC 可以有服务于虚拟 hart 的额外中断文件，称为 guest interrupt file；其数量恰好是 GEILEN"，客体外中断信号体现为 hypervisor CSR hgeip 的活跃位，VS 级还提供 vsiselect/vsireg/vstopei 间接访问；当设备 MSI 由客体操作系统配置时，"这些客户机物理地址必须由 hypervisor 配置的 IOMMU 翻译"，以重定向到正确客体的中断文件。[S04] 定时器：Sstc 引入 stimecmp 与 vstimecmp，hypervisor 可以直接为客体注入定时器中断，省去在 M 模式模拟定时器的高开销往返。[S07] 设备 DMA：RISC-V IOMMU 规范定义了设备侧的两阶段翻译，为设备直通与 MSI 重定向提供硬件基础。[S05] 机密计算：AP-TEE 技术组的产出（CoVE，Confidential VM Extension）"为 RISC-V 应用处理器平台定义支持机密计算架构的编程接口（ABI）"。[S06]

RVA23 把这些能力从"可选"推进到"profile 强制"。RVA23S64 的强制扩展中新增了 Sha（augmented hypervisor extension），其构成明确包含 H 扩展本体、Ssstateen（必须提供 sstateen0-3 与 hstateen0-3）、Shcounterenw 等；同时 Sstc、Svnapot、Ssu64xl 由 RVA22 的可选转为必选。换言之：从 RVA23 认证芯片开始，"有没有 H"不应再是问题，"实现得全不全"才是问题。[S02][S03]

图 2：RV64 虚拟化的机制与数据流（上半部：客体虚拟地址经 VS-stage（vsatp）与 G-stage（hgatp）两级页表翻译到机器物理地址，VMID 用于 TLB 打标；下半部：设备 MSI 经 IOMMU 两阶段翻译重定向到 IMSIC 的 guest interrupt file，客体外中断汇聚为 hgeip 位，定时器中断经 Sstc 的 vstimecmp 直接注入）。来源为 RISC-V H 扩展规范、AIA 规范仓库（IMSIC 章节）、IOMMU 规范仓库与 Sstc 规范归纳；为机制示意，不代表具体实现的时序或性能数值。[S01][S04][S05][S07]

需要强调的是，地址翻译只是必要条件：没有 AIA 的中断直投与 IOMMU 的 MSI 重定向，H 扩展只能提供“两级页表”形式的虚拟化，完整的机制数据流见图 2。

3.7 RISC-V 64 虚拟化软件栈现状

把 2026-09 的软件栈按成熟度排开，可以看到一条清晰的分界线：Linux 侧已经"上游可用"，Xen 侧还在"下游可跑"，嵌入式侧以静态分区自成一派。

两个重要的边界必须写进选型结论。其一，Xen RISC-V 的演示不等于可用：2026-09 的里程碑明确说明目标板"CPU 实现的是 H 扩展预批准草案（pre-ratification draft）"，Xen 为此做了专门适配，且补丁系列尚未进入上游；2026-05 的 Dom0 工作同样位于下游分支。这意味着在真实项目里，Xen RISC-V 目前只适合预研而非产线。其二，KVM RISC-V 的"上游可用"也不等于"全功能"：动态多租户场景依赖中断（AIA）、DMA 隔离（IOMMU）与设备模型的完整链条，而这些默认是芯片可选项、软件可选项。[S28][S30][S01][S04][S05]

另一个容易被忽略的软件事实是验证路径已经成熟。QEMU 的 RISC-V virt 机型"已为默认 CPU 启用 hypervisor 扩展，无需显式声明"，并且提供 8 个 virtio-mmio 传输设备与 PCIe 主机桥；香山昆明湖机型则直接暴露 IMSIC 与 APLIC。对开发者而言，在拿到硅片之前，完整的 KVM 客体启动、virtio 设备与中断路径都可以在 QEMU 上先行验证，这也是本报告建议的验收第一步。[S32][S33]

3.8 RISC-V 64 平台与芯片虚拟化能力

这张表最重要的信息不是"谁支持"，而是"支持"这个词在 RISC-V 上的三种成色：预批准草案实现（P550：能做、但要打补丁）、厂商宣称的完整实现（X100/C950：能力清单齐全）、以及 profile 标注（RVA23：体系结构层面的承诺）。工程上必须按"目标芯片手册 → 固件支持 → 内核版本 → hypervisor 工具链"四级逐一确认，任何一级缺失都会让虚拟化方案停在演示阶段。【P】

能力成熟度对比矩阵

图 3：RV64 虚拟化生态成熟度分级（自下而上级：规范层 H/AIA/IOMMU/Sstc/CoVE 已定义；硅片层 X100、C950、昆明湖等进入宣称或量产；内核与模拟器层 KVM 上游、QEMU 默认启用；产品层 Xen 下游、认证 hypervisor 与 Android AVF 尚无 RV64 一手证据）。来源为 RISC-V 规范仓库、KVM 版本日志、SpacemiT 与玄铁公开资料、Xen RISC-V 开发博客归纳；分级为本报告的研究判断，不构成产品验收结论。[S01][S06][S28][S33][S35][S14]

四层之间的落差——规范已就绪、硅片在宣称、软件在补齐、产品仍空白——正是第 4 章差距分析与第 7 章风险清单的来源，分层关系见图 3。

4. 国内发展、差距与机会

4.1 芯片与 IP：把"完整虚拟化"写进卖点

国内 RISC-V 阵营在 2025–2026 之交集体把虚拟化抬升为核心叙事。进迭时空（SpacemiT） 的 X100 核在官方产品页上被定义为"首款支持完整虚拟化的 RISC-V 处理器核"，明确列出 RV Hypervisor 1.0、RV AIA、RV IOMMU 三项扩展，并称可提供"CPU、内存、中断、IO 的完整硬件虚拟化能力"，基于 openc910 二次开发、遵循 RVA23、主频 2.5GHz@12nm；其 K3 芯片（8×X100 + 8×A100，60 TOPS，RVA23 标注）与其 CoM260 开发套件把这一能力带到了端侧 AI 与具身智能平台。[S34][S39]

阿里达摩院玄铁 走的是"性能 + 安全"双线：C950 宣称"支持 RVA23.1 的全部标配和可选扩展，原生支持 CoVE 机密计算"，并为服务器场景强调稳定性、安全性与资源利用率；C930 作为服务器级 CPU 交付，配合玄铁 Linux SDK，而 SDK 内容明确包含"Hypervisor 虚拟化、CoVE 安全框架"等子系统；产品矩阵还包括面向车规高可靠方向的 R908A。[S35][S36][S38]

香山（XiangShan） 提供学术与开源视角的参照系：昆明湖在 QEMU 官方机型文档中被标注为 RV64GCBSUHV——这个 ISA 字符串直接包含 H（hypervisor）与 V（vector），机型同时提供 IMSIC 与 APLIC，说明开源高性能核在体系结构层面已经按"带虚拟化的现代 profile"对齐。[S32][S37]

把三者放在一起看，国内产品化路线已经形成"服务器/云（C950 + CoVE）、边缘/端侧（K3/X100）、开源基线（香山）"的三角，且都把中断架构（AIA）与 IO 隔离（IOMMU）列为虚拟化的必备件——这与 3.6 节的机制分析一致：没有 AIA 与 IOMMU，"完整虚拟化"就只是两级页表。 [S04][S05][S33][S35]

4.2 软件与生态：SDK 先行，发行版与社区证据待补

国内厂商当前的软件策略是"随芯交付 SDK"：玄铁基于 Linux、Android、RTOS 三套操作系统提供 SDK，其中 Linux SDK 内含 Hypervisor 虚拟化子系统；进迭时空以 RVA23 平台 + 标准 CPU 编程范式降低迁移成本。这种打法的好处是客户拿到的是"芯片 + 虚拟化栈 + 工具链"的整包，缩小了从流片到场景验证的距离。[S36][S34]

但需要如实指出两个证据缺口。其一，国内发行版与社区对 RV64 虚拟化的具体贡献度本次未取得一手证据：KVM RISC-V 的上游维护者构成、国内企业在 Xen RISC-V 下游分支中的参与情况，均缺少可核查材料【?】。其二，认证 hypervisor 厂商的 RV64 产品化路线缺少公开证据：QNX、SYSGO、Green Hills 的公开材料以 ARM/x86 主体为主，SYSGO 仅把 RISC-V 列为"下一代架构"方向。【?】[S20][S21][S22]

4.3 差距与机会

差距可以归为三条，且都能从 3.8 节的"三种成色"里找到映射。第一是硅片实现的完备性：P550 的教训说明"实现了 H 扩展"与"符合最终规范"是两件事，预批准草案会让 hypervisor 需要专门的适配补丁；国内新核以"完整虚拟化"为卖点，反而更需要可复现的一致性测试来兑现承诺。[S28][S33] 第二是认证链条的缺位：车规与工业场景的虚拟化不是功能问题而是证据问题，QNX Hypervisor for Safety、PikeOS、INTEGRITY 的认证资质都建立在多年的 ARM/x86 证据链上，RV64 上尚无对等物；对国内厂商这既是差距也是窗口——认证 hypervisor 与 RV64 的组合尚无人占位。[S20][S21][S22] 第三是 Android 一侧的空白：AVF 的一手文档仍未覆盖 RISC-V，Android 在 RV64 上运行受保护虚拟机的路径缺少官方支撑。[S18]【?】

机会同样清晰。RVA23 把 Sha 变为强制项，意味着下一代通过 profile 认证的芯片默认具备 H 扩展与配套状态使能寄存器，"有没有"的问题会随时间消退，竞争转向"实现质量与软件栈完整度"。[S02][S03] CoVE 提供了差异化抓手：机密计算在 x86（TDX/SEV）与 ARM（pKVM）之后，RISC-V 的 ABI 定义尚在早期，C950 的"原生支持 CoVE"如果兑现为可验证产品，将直接对准云与边缘的机密计算需求。[S06][S35] 而嵌入式与车规的静态分区路线（Bao 的 RISC-V 流水线、QEMU 的完整验证链路）可以让 RV64 在"确定性整合"这个虚拟化最难的赛道上先建立可信案例。[S25][S32][S33]

5. 关键机制深挖

下面四节对应选型时最容易踩坑的四条机制线：地址翻译、中断与 MSI、时间分区、客体兼容。每节按"接口与实现依据 → 失效边界 → 验证条件 → 成本与权衡"展开，并给出可直接执行的验证动作。

5.1 两阶段地址翻译与 TLB：寄存器接口、页表实现与失效边界

接口与实现依据。 RISC-V 的两阶段翻译由一组明确的 CSRs 暴露给 hypervisor：hgatp 承载 G-stage 根页表物理地址、VMID 与 G-stage 翻译模式，vsatp 承载客体的 VS-stage 根；客体指针在 G-stage 下被扩展为 Sv39x4/Sv48x4/Sv57x4，多出的两级索引位来自 hgatp 本身。陷阱信息经 htval 与 htinst 提供——htval 给出出错的客体物理地址编码，htinst 在多数陷阱上给出触发指令的变换形式，这两个寄存器是二次缺页处理（hypervisor 为客体补页表）与设备模拟的实现基础。[S01] 失效接口由 hfence.vvma、hfence.gvma 及其合并形式承担：普通 sfence.vma 不保证对 G-stage 生效，这是移植 ARM/x86 代码时最容易写错的一处。RVA23 把 Svinval（细粒度失效）与 Svnapot（页表叶子合并）由可选转必选，使"批量改映射 + 精确失效"成为可依赖的基座。[S02][S03] Linux 侧自 5.19 起支持 Sv57x4 并改进了 HFENCE 路径，KVM 的页表与失效逻辑以此为准。[S08]

失效边界与已知故障。 规范要求 Sv39x4 的地址位 63:41 必须全为零，否则触发 guest-page-fault；换言之 G-stage 根页表必须 16 KiB 对齐且不得落在高位地址空间。[S01] VMID 的位宽被标为 UNSPECIFIED 且"可以为零"，当实现不支持 VMID 时，每次客体切换都必须做全量 TLB 失效——性能退化到与 ASID 复用同一水平，这类退化不会报错，只表现为随时间漂移的性能抖动，排查时需要靠性能计数器而非功能测试。[S01] 另一类难以复现的故障来自陈旧条目：hypervisor 忘记在修改映射后失效 TLB，或 VMID 回收策略不当导致新客体命中旧翻译，症状是间歇性访存错误而非确定性崩溃。边界条件还包括 VS-stage 与 G-stage 页大小不一致（客体用 64 KiB 叶子而 G-stage 只有 4 KiB/2 MiB/1 GiB 粒度）时的拆分成本。

验证条件。 最小验证集包括四项：(1) 在 QEMU virt（默认开启 H 扩展）上启动 KVM 客体并跑通 kselftest 中的 KVM 用例；若需覆盖中断与 MSI 路径，改用香山昆明湖机型（含 IMSIC/APLIC）。[S32][S33] (2) 用压力切换场景复现 VMID/ASID 回收缺陷：多客体反复启停并核对性能计数。(3) 用超配内存复现二次缺页路径，核对 htval 报出的地址与预期一致。(4) 复现测试应在真机上重跑一遍——QEMU 的 TLB 是功能模型，不体现真实容量与关联度带来的抖动。[S32]

成本与权衡。 两阶段翻译把一次 TLB miss 的页表遍历从 n 级扩到最多 m+n 级，最坏访存次数接近翻倍；TLB 需要同时缓存 VS 与 G 两级翻译，硬件成本随页面粒度与客体数量上升。[S01] 页表内存开销按 4 KiB 粒度满映射推算约为被映射内存的 1/512（每覆盖 512 页需新增一个 4 KiB 页表页），改用 2 MiB 大页可把它降到约 1/262144 并同时降低遍历深度，代价是内存粒度变粗、增量分配与内存回收变难——这是 hypervisor 侧"大页换 TLB 效率"的经典取舍。对选型而言：目标若是确定性与低开销（嵌入式/车规），应优先要求实现提供足够宽度的 VMID 与 Svinval；目标若是多租户云，则应把 VMID 宽度与 TLB 规模列入核对清单。[S01][S02]

5.2 中断与 MSI 虚拟化：从 PLIC 到 AIA 的接口演进

接口与实现依据。 传统 PLIC 是扁平的中断汇聚器，客体中断需要 hypervisor 在 hvip 上做软件注入，每次注入都是一次陷入。AIA 用两级结构取代它：APLIC 负责线中断汇聚（可配置为直接交付或 MSI 模式），IMSIC 负责 MSI 交付，并为每个 vCPU 提供独立的中断文件。[S04] 客体侧看到的是 vsiselect/vsireg/vstopei 这一窗口：VS 级软件通过它配置自己的中断文件，无需知道物理 IMSIC 的编号；hypervisor 侧用 hgeip（外部中断挂起）与 hgeie（使能）观察与路由客体外部中断，GEILEN 决定可用的客户机外部中断行数。[S01][S04] 当设备的 MSI 由客体操作系统配置时，规范要求这些客户机物理地址由 hypervisor 配置的 IOMMU 翻译，从而把 MSI 写重定向到目标客体的中断文件——这是"直通设备 + MSI"能工作的前提。[S04][S05] 定时器一侧，Sstc 引入 stimecmp/vstimecmp，hypervisor 可直接为客体注入定时器中断，省去在 M 模式代理定时器的高开销往返。[S07] Linux 6.4 落地 AIA CSR 虚拟化，6.10 补齐 SBI v2.0 的 PMU 与客体采样路径。[S15][S16]

失效边界与限制。 规范明确允许 hgeip/hgeie 的若干位为 UNSPECIFIED 且"可以为零"——即"有 H 扩展、有 AIA"不等于"能做中断直投"；当 GEILEN 为 0 时，实现必须回退到软件注入，延迟升高且边沿语义需要软件补齐，这是中断丢失类故障的常见来源。[S01][S04] 另一类故障在 MSI 翻译链路上：IOMMU 未启用或 MSI 表配置错误时，直通设备的中断会写到物理中断文件而非目标客体，表现为设备静默或中断串扰到相邻客体——这类异常往往要在多设备压力下才暴露，单设备冒烟测试很难发现。此外，PLIC 与 AIA 并存的平台（部分早期芯片与 QEMU 机型）需要客体侧兼容两套发现机制，设备树与 ACPI 的中断描述差异会直接导致引导期中断不可用。[S04][S32][S33]

验证条件。 (1) 在昆明湖机型上验证客体中断注入：核对客体 /proc/interrupts 计数与 hypervisor 侧 hgeip 挂起位一致，并确认 Sstc 定时器不产生周期性陷入。[S33] (2) 对直通网卡做多队列 MSI-X 压力测试，在相邻客体同时收包时核对中断不串扰——这是 MSI 翻译错误最可靠的复现方式。(3) 版本矩阵：分别在 GEILEN > 0 与仅软件注入两类配置下运行同一客体，比较中断延迟与吞吐，确认回退路径质量。(4) 验收条件建议写成可测量指标：中断注入延迟上限、压力下零丢失、直通设备在线速下的中断合并行为符合预期。

成本与权衡。 IMSIC 为每个 vCPU 提供独立中断文件，文件数量与 GEILEN 直接决定硬件面积与可支持的 vCPU 规模，这是相对 PLIC 的主要成本；收益是免陷入的中断直送与天然的多租户隔离。[S04] 对小规模、静态分区的嵌入式系统，PLIC 加软件注入的成本更低且行为可静态分析，AIA 的收益主要体现在动态多租户与直通设备密集的场景；选型时不应把 AIA 当作"越新越好"的默认项，而应结合客体数量与设备直通需求评估。[S04][S05]

5.3 静态分区与动态调度：实时性、确定性与资源开销

接口与实现依据。 静态分区路线的接口形态是"配置期确定"：ARINC 653 用分区与主时间帧（major time frame）的窗口调度表定义每个分区的执行时间与顺序，分区之间通过采样端口与队列端口通信，任何一个分区的故障不得影响其他分区。[S23] 分离内核把它下沉为最小可信计算基：QNX Hypervisor for Safety 以 QNX OS for Safety 为底座并附带功能安全资质，PikeOS 以"RTOS & Hypervisor"一体形态提供认证套件，INTEGRITY Multivisor 声称覆盖 ASIL D、DO-178B A 级与 SIL3。[S20][S21][S22] 开源侧，Bao 用编译期确定的分区表与最小 hypervisor 实现时间与空间隔离，并同时维护 ARM 与 RISC-V 两条流水线；Jailhouse 以 Linux 为管理核、把裸机或 RTOS 负载作为静止分区装入。[S25][S26] 与之相对，动态调度路线（KVM 调度 guest 的 vCPU）复用了通用调度器的公平性与利用率优势，但无法对单次调度延迟给出硬上限。[S09][S10]

失效边界与故障模式。 静态分区的确定性完全来自配置期固定：分区表一旦上线，新增客体必须重新编译、重新做时间与空间分析，必要时重新认证——动态负载无法自适应。[S23][S25] 更隐蔽的失效边界在共享硬件资源：即便时间窗口严格隔离，若 L2/L3 缓存与内存带宽未做隔离（缓存着色、带宽配额或分区），一个分区的大内存流量会击穿另一个分区名义上的最坏执行时间，症状是偶发超时而非逻辑错误——这类故障在实验室难以复现，却会在现场长时间运行后出现。[S22][S25] 边界条件还包括中断路径：中断注入需要经过 hypervisor 转发或共享内存握手，任何一段引入不可界定延迟都会破坏最小 hypervisor 的承诺。[S20][S23]

验证条件与复现方法。 分区系统的验收必须以最坏情况而非平均值定义：(1) 最坏执行时间测量需覆盖缓存冷热两种状态，并在多个分区同时施加最大内存压力下测量；(2) 中断最坏延迟需用硬件时间戳而非内核时间测量，并长时间运行（建议不少于 24 小时）以捕捉漂移；(3) 认证路径上的验收条件由功能安全标准定义——ARINC 653 一侧按 DO-178C/ED-12C 的目标做符合性验证 [S23]，安全认证则以 ISO 26262、IEC 61508、IEC 62304 等对应标准的证据要求为准 [S20][S21][S22]；(4) 配置冻结后做变更影响分析——任何分区表改动都应触发完整的重新验证，这一点应写进流程而不是靠人记忆。

成本与权衡。 静态分区用弹性换可证明性：时间窗口会浪费一部分 CPU 利用率（窗口按最坏执行时间分配，浪费量级可达一到三成），换来的是不必为动态调度器本身做认证——而认证成本正是车规与航电 hypervisor 的主要支出项。[S20][S23] 动态调度（KVM）把利用率做高、生态做宽，代价是无法给出跨客体的硬实时保证；更关键的是管理域的代码基线无法通过高等级安全认证，这正是 pKVM 把 Linux 降级为被 stage-2 隔离的第一个域、用 hypercall 约束其能力的动机，也说明"开源动态方案 + 高等级认证"的组合在架构上并不成立。[S11] 选型结论是清晰的：预算里有认证与确定性要求时选静态分区（Bao、Jailhouse 或商业认证品），需要通用生态与运维效率时选 KVM，二者不是同一赛道。

5.4 客体兼容与二进制生态：virtio、SBI 与设备模型

接口与实现依据。 客体兼容的接口边界由三层构成：设备发现层用设备树或 ACPI，设备抽象层用 virtio，架构服务层用 SBI。virtio 1.2 把设备抽象为 MMIO、PCI 与通道三种传输，并定义网络、块、控制台等标准设备类型，使同一客体镜像可在不同 hypervisor 上运行而无需改驱动。[S31] RISC-V 侧，客体内核通过 SBI 获取时钟、IPI、远程栅栏与重启等服务，SBI 版本协商决定 hypervisor 暴露的能力集；KVM RISC-V 自 5.16 进入主线时即提供基础服务，6.6 起支持 ONE_REG 等迁移所需接口，6.10 补齐 SBI v2.0 的 PMU 扩展。[S14][S15][S16] QEMU 的 RISC-V virt 机型是事实标准参考平台：默认开启 H 扩展，virtio-mmio 与 virtio-pci 齐备；香山昆明湖机型额外暴露 IMSIC 与 APLIC，使"中断 + 虚拟设备"的完整链路可在硅片到位前先行验证。[S32][S33]

失效边界与限制。 第一类是协商类故障：hypervisor 报出的 SBI 版本低于客体期待时，功能退化为陷入式模拟，表现为性能下降而非功能失效，容易被误判为"慢"而不是"配置不一致"；反过来，hypervisor 声称支持某扩展却未完整实现，客体会在不可预期路径（典型是系统复位与 PMU）上异常。[S15][S16] 第二类是设备模型混用：virtio-mmio 与 virtio-pci 在中断与 DMA 语义上的差异会让一部分发行版安装镜像引导失败。[S31][S32] 第三类是固件描述缺口：RISC-V 平台 ACPI 的成熟度低于 ARM/x86，不少发行版仍假设设备树，导致同一客体镜像出现"ACPI 平台可用、DT 平台不可用"的两极结局。[S32] 边界条件还包括客体内核版本对 H 扩展的假设——较老内核在 H 扩展平台上可能因缺少 CSR 保存恢复路径而异常，需在选型时明确最低内核版本。

验证条件。 (1) 设备模型矩阵：在 QEMU virt 上分别以 virtio-mmio 与 virtio-pci 引导同一客体，核对中断分配与磁盘吞吐——虚拟化验收不应只看"能不能起来"。(2) SBI 版本矩阵：以 v0.2/v0.3/v2.0 三档分别引导，确认降级路径行为符合预期。(3) 固件路径实测：用主流发行版安装镜像分别走设备树与 ACPI 两种引导路径，任一失败都要记录为阻塞项。(4) 迁移验收：若需要在线迁移，必须验证 ONE_REG 等状态同步接口与设备状态序列化在目标平台上的完整性。[S15][S16][S31][S32]

成本与权衡。 virtio 的通用性以性能为代价：标准 virtio 每次 I/O 都有 vCPU 陷入与后端线程切换成本，长路径 I/O 需要 vhost-user 或硬件队列旁路才能接近原生。[S31] 设备直通性能接近裸机，但要求 IOMMU 提供 DMA 隔离并牺牲迁移能力——直通设备的状态难以序列化，这是云厂商在通用实例与性能实例之间切分产品线的根本原因。[S05][S31] 对嵌入式场景还有一条成本线：virtio 需要客体内核具备驱动支持，若目标是运行既有 RTOS 二进制，则往往退化为"静态分区 + 共享内存"而非 virtio 模型，这与 5.3 节的结论相互印证。[S23][S25]

6. 演进方向与情景

6.1 技术走向

对 2026–2030 年的技术走向给出四点判断，均以可查验的规范与版本事件为依据。

第一，虚拟化从可选能力变成默认能力。RVA23 把 Sha（H 扩展及其配套状态使能寄存器）、Sstc、Svnapot、Ssu64xl 列入强制项 [S02][S03]，意味着下一代通过 profile 认证的 RV64 芯片天然具备运行 KVM 或 Type-1 hypervisor 的要素。竞争随之从"有没有 H"转向"实现质量"：VMID 宽度、GEILEN、IOMMU 细节与固件描述会成为差异化参数。[S01][S04][S05]

第二，中断与 IO 隔离的规范链已经闭环。AIA 提供 IMSIC/APLIC 两级模型，IOMMU 规范提供设备侧两阶段翻译与 MSI 重定向，Sstc 解决定时器注入 [S04][S05][S07]；剩下的工作是把这些规范落实到硅片与 hypervisor 代码里——Linux 6.4 与 6.10 的 AIA、PMU 落地是上游侧的进展 [S15][S16]，而 Xen RISC-V 直到 2026 年才走到真机启动客体域且尚未上游 [S28][S30]，说明 Type-1 侧仍在补课。

第三，机密计算成为 RV64 的目标场景而非附属功能。CoVE（AP-TEE）定义了机密虚拟机的编程接口与 ABI，国内厂商已把"原生支持 CoVE"作为旗舰核卖点 [S06][S35]；但可验证的产品化案例目前缺少一手材料【?】。

第四，Android 的 RV64 虚拟化路径是明显短板。AVF 的一手文档仍以 ARM 为语境、以 pKVM 为参考 hypervisor [S18][S19]，RISC-V 上运行受保护虚拟机的官方支撑缺失【?】；若 Android on RISC-V 进入量产，这一缺口会最先在受保护内容、DRM 与安全支付场景暴露。

6.2 到 2028 年的三种情景

三条情景的共同变量是软件栈完整度而非 ISA 能力：架构侧要素（H、AIA、IOMMU、Sstc）已经齐备，瓶颈在实现细节与生态成熟度 [S01][S04][S05][S07]。

6.3 观察信号

用于在 12–24 个月窗口内判断情景走向的早期信号，建议按季度复核：

1. Xen RISC-V 是否上游：Dom0 与客体启动补丁进入上游树是 Type-1 路线可用的前置条件，目前仍在下游分支。[S28][S30]
2. 认证 hypervisor 的 RV64 公告：QNX、PikeOS、INTEGRITY 任意一家发布 RV64 支持或认证计划，将直接改变车规与航电的选型格局。[S20][S21][S22]
3. QEMU 机型与固件描述的收敛：香山昆明湖之外是否出现更多带 IMSIC/APLIC 且 ACPI 可用的机型，决定"硅片前验证"的覆盖度。[S32][S33]
4. KVM RISC-V 的版本日志：是否出现 IOMMU 与嵌套虚拟化的上游条目，是"能否做多租户直通"的分水岭。[S15][S16]
5. Android 侧文档变化：AVF 文档是否加入 RISC-V 语境，是 RV64 进入移动量产链的先行指标。[S18]

7. 建议与验收

7.1 先回答三个问题

问题一：RV64 上现在能不能做虚拟化？ 能，但要分层看：内核内虚拟化（KVM）已上游可用，开发验证链路（QEMU virt 与香山昆明湖机型）完备 [S14][S15][S16][S32][S33]；Type-1 开源方案中静态分区类（Bao、Jailhouse、Xvisor）可用，Xen 仍在下游分支 [S25][S26][S27][S28][S30]；机密计算（CoVE）与 Android 受保护虚拟机尚无可验证产品 [S06][S18]【?】。

问题二：应该选哪条路线？ 取决于三个问题：是否要求确定性与认证、是否需要运行异构客体、是否需要多租户与迁移。7.2 节给出按场景的建议与理由，判断依据来自第 3 章的机制基线与第 5 章的失效边界分析。

问题三：什么时候做？ 建议把虚拟化能力核对前置到硅片选型阶段。原因是第 3 章呈现的三种成色差异：ISA 已就绪、软件在补齐、产品在宣称——把"实现细节核对"与"QEMU 先行验证"放在流片之前，可以避免拿到芯片后才发现 VMID、GEILEN 或 IOMMU 不可用。[S01][S04][S05]

7.2 场景选型表

7.3 工作包与验收条件

按"先行验证、选型核对、场景落地、生态跟进"四段组织，每个工作包配可验收指标：

建议—验收矩阵

7.4 不建议做法

• 不建议把"宣称支持虚拟化"直接写入选型结论。 ISA 字符串里带 H 不代表 VMID、GEILEN、IOMMU 完整可用，规范明确为这些项留了实现自由度 [S01][S04]，必须逐项核对。
• 不建议在 RV64 上为生产系统长期维护下游 hypervisor 分支。 Xen RISC-V 至今未上游 [S28][S30]，下游分支意味着维护成本与安全响应责任自担。
• 不建议在未做缓存与带宽隔离的平台上部署混合关键性负载。 时间窗口隔离无法阻止共享资源干扰，故障表现为偶发超时 [S22][S25]。
• 不建议用容器替代虚拟机解决异构内核或强隔离需求，也不建议用虚拟机替代容器。 两者解决的隔离问题正交，混用会同时付出两边的成本 [S12][S13]。
• 不建议把设备直通当作通用默认项。 直通牺牲迁移能力并要求 IOMMU 隔离完备，应作为性能实例的例外而非基线 [S05][S31]。

8. 不确定性与研究限制

8.1 主要不确定性

1. 厂商宣称到产品实现的兑现度。 X100 的"完整虚拟化"、C950 的"原生支持 CoVE"目前均为厂商口径，缺少第三方实测或客户案例 [S34][S35]。
2. 认证 hypervisor 的 RV64 时间表。 QNX、PikeOS、INTEGRITY 均把 RISC-V 列为方向，但未检索到 RV64 认证产品的一手材料 [S20][S21][S22]。
3. Android 在 RV64 上的虚拟化路径。 AVF 文档未覆盖 RISC-V，本报告的依据是文档缺口而非官方否定 [S18]。
4. Xen RISC-V 的上游时间。 真机启动客体域已经实现，但补丁在下游分支，上游化没有公开承诺 [S28][S30]。
5. 实现细节的可获得性。 VMID 宽度、GEILEN 等参数通常不出现在产品简介中，需要向厂商索取或实测，本报告无法代替这项工作 [S01][S04]。

主张—证据矩阵

8.2 研究限制

本报告基于公开资料与规范正文撰写，未做芯片实测；正文中的量级类表述（如时间窗口浪费比例、页表内存开销比例）均为按规范与常规实现推算的工程估计，已避免作为论据使用，实测应以目标平台的测量结果为准。检索截点为 2026-09-29。后续建议按 6.3 节观察信号与 7.3 节 WP4 持续更新；任一触发条件成立（认证 hypervisor 公告 RV64、Xen 上游化、AVF 文档覆盖 RISC-V、CoVE 出现可验证产品）时应重做第 6 章的情景评估。[S20][S28][S18][S06]

参考来源

附录：研究方法

• 检索顺序：规范优先、上游优先、一手优先。RISC-V 规范仓库与 Linux 内核发布日志为第一层证据；厂商产品页与媒体报道为第二层；社区与二手资料仅用于线索发现，不作为结论依据。
• 链路核验：台账中所有链接均经 HTTP 状态核验；GitHub 页面间歇不可达时改用 GitHub API 确认仓库与文件内容存在，状态在台账中如实体现。
• 交叉验证：关键结论要求至少两个独立来源；厂商口径与规范、上游事实分开标注，证据强度见 8.2 主张—证据矩阵。
• 证据分级：正文以【C】【C*】【S】【P】【?】区分规范事实、规范推论、已发布状态、工程判断与证据缺口，标记定义见文首"可靠性标记"。
• 工具链：Markdown 撰写与结构校验（本地校验脚本）、Graphviz 生成 SVG 图并在渲染阶段内嵌、静态 HTML 渲染后由浏览器验证图与表格加载。