Axvisor架构优化

[ZR233]

Axvisor 配置与架构解耦技术方案

1. 背景与动机

当前 axvisor 项目包含三个核心 crate：

• axvisor：顶层虚拟化与平台管理逻辑
• axvm：虚拟机（VMM / guest execution）相关实现
• axdevice：虚拟/直通设备抽象与注册

随着对多架构（如 RISC-V、AArch64、x86_64 等）与多平台（不同 SoC / 板级）的支持增加，项目内部出现以下问题：

1. arch 相关条件编译（#[cfg(...)]）在 axvm 与 axdevice 中大量散落，难以维护。
2. 配置项（arch、平台、虚拟设备开关、内存/核数限制等）分布于：
   • axvm（如启动参数、MMU/内存模型）
   • axdevice（设备选择、初始化）
   • axvmconfig / axvisor_api（跨 crate 传递结构）
     造成信息路径割裂。
3. 配置“流向”不清晰：谁定义 / 谁持有 / 谁消费不明确。
4. 架构耦合阻碍复用：axvm、axdevice 难以在其他宿主或测试环境中独立使用（例如单元测试 / 模拟）。
5. 虚拟设备在axdevice直接注册，造成配置需经过axvisor->axvm->axdevice，跨多个crate，重复传递。
6. 架构感知逻辑与“功能逻辑”耦合，增加新增架构或改动现有策略的风险与成本。
7. API接口不统一，同一个库中同时使用多种不同的接口风格，包括trait直接作为接口、axvisor-api外部函数和extern "C"函数。
8. axvcpu本意是设计为抹除架构间vcpu差异，但实际是各架构差异较大，在这一层抹除差异造成接口过度复杂，无法根据特性优化。
   vCPU核心功能差异：

功能特性	ARM64	x86_64	RISC-V	抽象复杂度
虚拟化扩展	VHE/VNCR	VMX	H-extension	⭐⭐⭐
上下文切换	EL2/EL1切换	VMCS管理	HSTATE管理	⭐⭐⭐
异常处理	Syndrome解析	Exit Reason	Exit Cause	⭐⭐
内存管理	Stage-2页表	EPT/NPT	Sv-39页表	⭐⭐⭐
寄存器模型	通用+系统寄存器	通用+MSR	通用+CSR	⭐⭐

虚拟中断控制器差异对比：

特性	ARM vGIC	Intel APIC	RISC-V IMSIC	接口统一难度
消息传递	SGI/ID/PPI	LAPIC/IOAPIC	MSI	⭐⭐⭐⭐⭐
路由机制	Affinity/Target	Fixed/Lowest	AIA	⭐⭐⭐⭐
优先级	32级优先级	8级优先级	配置优先级	⭐⭐⭐
虚拟化支持	vGICv2/vGICv3	APICv	IMSIC+HVIP	⭐⭐⭐⭐⭐
配置接口	Distributor	MSR访问	MMIO访问	⭐⭐⭐⭐

2. 目标

目标类别	目标描述	衡量指标
架构解耦	axvm、axdevice 不再直接包含 arch 特定条件编译	arch 条件编译迁移到 axvisor
配置集中	所有外部可调配置集中在 axvisor	单一入口（Configuration Root）
接口稳定	axvm / axdevice 通过清晰 API 接收已解析配置	API 文档化，函数/类型变更频率降低
可测试性	可在无真实硬件 / 无特定 arch 条件下运行核心逻辑测试	CI 引入“generic host” profile
可扩展性	支持新增 arch / 虚拟设备时最小化侵入	新增 arch 时仅修改 axvisor 层及少量 adapter

3. 优化方案

新的设计理念：从"vCPU层抹除差异"转变为"VM层抹除差异，vCPU求同存异"。核心相似功能抽象，架构特性独立，最小公约的函数组合，最终在VM层抹除架构差异

1. 单一配置源（Single Source of Truth）：所有运行参数（arch、平台、设备编排、资源限制等）在 axvisor 中构建并冻结。
2. 明确数据流方向：配置只“下行”到 axvm、axdevice；运行期状态可“上行”以供监控。
3. 设备注册位置由axdevice直接注册改为暴露注册接口，在axvisor层进行配置和注册，避免跨多个crate传递配置。
4. Arch 隔离：arch 专属代码集中于 axvm::arch::*。

新分层架构

管理层 (axvisor): 负责虚拟机的高层管理逻辑，如VM生命周期管理、vCPU调度和资源分配。

VM层 (axvm): 提供统一的虚拟化抽象接口，定义trait和基础类型，协调各架构实现，提供给axvisor的接口已抹除架构差异。

架构层 (axvm/arch): 实现架构特定的虚拟化功能，为axvm接口提供实现，隔离架构相关代码，每个架构独立维护。每个架构模块内部依赖具体的实现组件。

架构实现层: 包含具体的架构实现模块，如arm_vcpu、arm_vgic、x86_vcpu等，为架构层提供底层功能支持。

架构共性层 (axvm/common): 在vm层级内，提供各架构通用的辅助功能和工具函数，减少重复代码。

14. 结论

通过将所有架构相关与配置决策逻辑上移至 axvisor，并为 axvm、axdevice 提炼统一抽象与配置注入流程，可显著提升：

• 可维护性（减少散点条件编译）
• 可扩展性（新增架构/设备成本降低）
• 可测试性（无 arch 依赖的核心逻辑复用）
• 配置透明度（单入口可观测）

[shilei-massclouds]

赞成把分散的配置、分散的体系结构条件编译等进行集中处理，但是感觉不一定集中后都直接放置到axvisor。
是否可以考虑：把arch相关的集中到一个crate，arch无关的通用配置集中到一个crate，axvisor还是仅作为一个顶级的组织者，并不包含复杂的具体职责？

[ZR233]

收到，后面我设计一下项目结构

[ZR233]

重构前的结构

重构后的结构

1. 虚拟机需要大量 Arch 特定的虚拟化支持，而 axhal 统一了各 arch 接口，抹除了 arch 差异，导致每需要一个功能，都需要在 axhal 中添加对应 arch 的实现，而其他 arch 则需要添加空实现，增加了维护成本。

2. 同样的，axvcpu 也统一了 各 arch 的 vcpu 接口，导致每增加一个 vcpu 功能，都需要在 axvcpu 中添加对应 arch 的实现，增加了维护成本。

3. 全部组件依赖 axvisor-api, 任何组件想要使用其他组件的功能，都需要通过 axvisor-api 进行间接调用，而 arch 开发中，会增加 arch 相关的特有函数，这又需要在 axvcpu 或 axhal 中增加其他 arch 空实现，并修改 axvisor-api，进一步增加了 axvisor-api 修改的可能性，导致几乎任何修改，都需要修改 axvisor-api、axhal， 而修改 axvisor-api, axhal，则会导致修改所有依赖库，进而引发修改所有 axplat 等等几乎所有组件。

重构后

1. 将所有架构相关（arch-specific）的实现收敛到 AxVm 模块：由 AxVm 统一负责虚拟机生命周期管理，并对外提供一致的虚拟机管理接口。AxVm 内部按架构选择对应的 VCPU 实现与地址空间实现，避免 arch-specific 代码分散在各个模块中。各架构的 VM 也不再通过 axvcpu 抹平差异，而是直接调用 arch_vcpu；由 arch_vcpu 以各自方式实现/适配 axvcpu 的能力，从而复用通用逻辑，并允许每个 ArchVm 以自己的方式组合 vcpu、vdevice、addrspace 等组件。

2. axvisor-api 改动：各模块不再直接依赖 axvisor-api，而是各自暴露最小必要接口，降低模块变更引发的全局联动修改。

3. 对 ArceOS 的依赖：行为上仅依赖 std 部分；虚拟化相关的特有能力通过 crate-interface 或直接依赖 HAL 层实现，尽量避免对 ArceOS 做侵入式修改。

[shilei-massclouds]

以前的设计抽象层次较多，倾向于垂直化管理；新设计减少了部分中间层，倾向于扁平化。属于各有利弊。
但我们目前的项目规模比较小，人员比较少，我赞成扁平化的倾向，优先考虑如何去减少层次和更简单直接，以减小当前开发和维护的成本。
我认为可以开个分支按照新设计实验性的改一下，看看能否达到上述效果和会不会引起意外的问题。

[hky1999]

Who is responsible for the lifetime management and scheduling of each vCPU

[ZR233]

继续深化设计
如图所示，AxVm 通过状态机管理虚拟机生命周期与资源分配。

1. 整体结构：

• AxVisor 内核维护 vms 容器，承载多个 Vm 实例。
• Vm 持有静态配置（image_loader, fdt）以及共享的运行时数据 VmData（Arc 管理）。

2. 状态管理 (VmData)

• VmData 记录基础信息（ID、Name）与核心状态 status: RWLock<VmMachine>。
• VmMachine 为枚举，涵盖三种状态数据：
  • InitData：配置、vcpus: Vec<VCpu>、addrspace: Mutex<>，启动前的准备态。
  • VmRunData：start() 时将 addrspace 等从 InitData move 进来，初始化 v-device-manager: Mutex<>，提供 stop(), suspend(), is_running() 运行时接口。
  • StoppedData：停止后保留统计信息 statistic ...。

3. VCPU 与线程模型

• VCpu 同时包含架构相关 arch-vcpu 与通用 axvcpu 部分，持有指向 VmData 的 Weak，避免循环引用。
• 进入运行态后，为每个 vcpu 创建线程（Thread1/Thread2...），执行 loop fn run()；退出时走 Stop(drop) 路径释放资源。

通过在状态间显式迁移资源（Move）并结合 Arc/Weak 引用控制，AxVm 将不同阶段的能力与数据隔离，降低跨模块耦合并确保生命周期安全。

[shilei-massclouds]

ok, 单看这个设计，目前还没有想到什么问题。

[hky1999]

ok, 单看这个设计，目前还没有想到什么问题。

感觉这样会让 axvm 与 arceos 强耦合

使得我们把 axvisor 的各个模块单独发布成 crate 这个事情 meaningless

[ZR233]

ok, 单看这个设计，目前还没有想到什么问题。

感觉这样会让 axvm 与 arceos 强耦合

使得我们把 axvisor 的各个模块单独发布成 crate 这个事情 meaningless

axvm 只依赖arceos std兼容接口，通过feature控制，在发布时用std编译发布即可

[ZR233]

#329 以arm为例完成可行性验证

[ZR233]

#330 客户机地址映射逻辑重构

[ZR233]

https://github.com/arceos-hypervisor/axvisor/blob/next/doc/changelog/v0.3.0/AxVCpu.md 代码验证