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. 架构感知逻辑与“功能逻辑”耦合，增加新增架构或改动现有策略的风险与成本。

2. 目标

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

3. 优化方案

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

14. 结论

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

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

[shilei-massclouds]

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

[ZR233]

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