重构 axvisor 客户机加载方案

[bullhh]

背景与问题分析

当前Axvisor启动客户机需同时提供设备树文件（如linux_qemu.dtb)和客户机配置文件（如linux_qemu_aarch64.toml），存在以下问题：

• 配置冗余：设备树与配置文件中的物理CPU映射（phys_cpu_ids）、内存区域（memory_regions）、直通设备地址等参数需手动同步，使用复杂。

• 部署低效：修改客户机配置后需重新编译和下载Axvisor，无法动态更新。

优化目标

本次优化设计主要致力于实现以下两个核心目标：

• 减少启动配置复杂度：通过自动从主机设备树解析参数，减少了启动 Axvisor 所需的手动配置项和参数数量。这降低了用户的配置负担，减少了因手动输入错误导致启动失败的可能性，提升了使用便捷性。
• 增强工程实用性与灵活性：优化使 Axvisor 更能适应实际工程项目的需求。用户可以更方便地根据需要修改客户机配置参数，例如控制台选择客户机配置和不重新编译下更换客户机，增强了系统在不同场景下的适用性和可维护性。

优化主要分为三个阶段：

阶段	核心目标	关键收益
阶段1	（简化配置）动态生成客户机设备树	不再使用客户机设备树文件，并减少客户机配置项
阶段2	（工程应用）从文件系统中读取客户机配置文件	修改客户机配置无需重新编译Axvisor
阶段3	（工程应用）控制台动态配置	axvisor启动时动态加载/修改客户机配置

具体实现方案

阶段一

一、设备树自动生成机制

1. 设备树来源：

• 主机设备树：Axvisor启动时加载的硬件描述树（.dtb）。

2. 生成逻辑：

关键步骤说明：

1. 直通设备处理（passthrough_devices）：
   • 根据设备节点名（如uart@2800d000）自动获取物理地址、长度、中断号。
   • 级联父节点：直通设备时自动包含其父总线/控制器节点，确保硬件拓扑完整。
2. 内存映射（memory_regions）：
   • 根据配置文件生成客户机设备树memory节点。
3. CPU映射（phys_cpu_ids）：
   • 自动生成客户机CPU节点，移除冗余的phys_cpu_sets字段。

3. 具体实现：

1. 直通设备处理（passthrough_devices）：

   如下设备树节点中，可以通过reg读取出基地址为0x2800d000, 大小为0x1000,读出相关数据后可使用vm_cfg.add_pass_through_device(pt_dev)函数将相关节点信息添加到config文件中供后续使用。

   uart@2800d000 {
       compatible = "arm,pl011\0arm,primecell";
       reg = <0x00 0x2800d000 0x00 0x1000>;
       interrupts = <0x00 0x54 0x04>;
       clocks = <0x0c 0x0c>;
       clock-names = "uartclk\0apb_pclk";
       status = "okay";
   };
   

   修改前后对比：

   passthrough_devices = [
       ["intc@8000000", 0x800_0000, 0x800_0000, 0x50_000, 0x1], #[name, base_gpa, base_hpa, length, irq_id]
       ["pl011@9000000", 0x900_0000, 0x900_0000, 0x1000, 0x1],
       ["pl031@9010000", 0x901_0000, 0x901_0000, 0x1000, 0x1],
   ]
   
   passthrough_devices = [
       "intc@8000000",   
       "pl011@9000000",
       "pl031@9010000"
   ]
   

2. 内存映射（memory_regions）：

   使用fdt-parser仓库可实现主机设备树文件的读取，使用vm-fdt仓库可实现客户机设备树文件的生成。

3. CPU映射（phys_cpu_ids）：

   与处理直通设备相同，读取phys_cpu_ids在设备树中顺序，自动填充phys_cpu_sets字段。

   以phytium-pi e2000开发板为例，配置文件中：

   cpu_num = 3
   phys_cpu_ids = [0x200, 0x201, 0x100]     # cpu逻辑ID
   phys_cpu_sets = [1, 2, 8]                # 物理CPU掩码位
   

   axvisor的cpu节点如下，通过phys_cpu_ids和设备树节点可以推断出phys_cpu_sets

    cpu@0 {
            device_type = "cpu";
            compatible = "phytium,ftc310\0arm,armv8";
            reg = <0x00 0x200>;
            ...
    };
    cpu@1 {
            device_type = "cpu";
            compatible = "phytium,ftc310\0arm,armv8";
            reg = <0x00 0x201>;
            ...
    };
    cpu@100 {
            device_type = "cpu";
            compatible = "phytium,ftc664\0arm,armv8";
            reg = <0x00 0x00>;
       		...
    };
    cpu@101 {
            device_type = "cpu";
            compatible = "phytium,ftc664\0arm,armv8";
            reg = <0x00 0x100>;
            ...
    };
   

二、配置文件精简

优化后的配置文件仅保留必要参数：

# Vm base info configs
[base]
id = 1
name = "linux"
vm_type = 1
cpu_num = 4
phys_cpu_ids = [0x00, 0x100, 0x200, 0x300]

[kernel]
entry_point = 0x4000_0000
kernel_load_addr = 0x4000_0000
dtb_load_addr = 0x4008_0000
ramdisk_load_addr = 0x4020_0000
image_location = "memory"
kernel_path = "Image.bin"
ramdisk_path = "ramdisk.img"

[memory]
regions = [
    [0x4000_0000, 0x4000_0000, 0x7, 1] 
]

[devices]
passthrough_devices = [
    "intc@8000000",    # 自动解析地址
    "pl011@9000000",
    "pl031@9010000"
]
emu_devices = [ ]

移除的冗余项：

• dtb_path→ 不再需要，客户机设备树由主机设备树文件和客户机配置文件共同生成。

• phys_cpu_sets→ 通过phys_cpu_ids动态计算位掩码。

• passthrough_devices参数精简。

阶段二

三、 配置文件的存储与加载

1. 设计目标：

• 解耦配置与代码：将客户机配置文件(axvisor/configs/vms/xxxxx.toml)从Axvisor源码中剥离，避免因客户机配置更新触发Hypervisor重编译。

• 动态加载能力: 支持初始化时从文件系统读取配置文件，客户机重启即可生效，无需重启Axvisor宿主机。

• 兼容直通存储架构：利用设备直通特性，使Axvisor与客户机共享相同存储设备和相同文件系统格式（如EXT4），简化存储管理。

2. 存储架构设计

• 配置文件存储位置

  配置模式	存储位置
  image_location="fs"	客户机文件系统固定路径（如 /guest/vms1/guest_config.toml）
  image_location="memory"	编译时嵌入Axvisor二进制文件

• 文件系统要求

Axvisor需挂载与客户机相同的文件系统（如EXT4/FAT32），确保直通设备可被双向识别。

• 路径标准化：

  在文件系统根目录创建guest文件夹，内部存放客户机配置文件和镜像

  /guest/                  # 根目录
  ├── vms1/                # 客户机1专属目录
  │   ├── vm_config.toml   # 客户机1配置文件（TOML格式）
  │   └── Image            # 客户机1系统镜像文件（如linux）
  └── vms2/                # 客户机2专属目录
      ├── vm_config.toml   # 客户机2配置文件（TOML格式）
      └── arceos.bin       # 客户机2系统镜像文件
  

3. 运行时加载流程

阶段三

四、控制台动态配置客户机

1. 设计目标

• 通过控制台交互界面实时生成/修改客户机配置文件（TOML格式）。
• 支持配置模板选择、参数修改（CPU/内存/设备直通等）。

2. 配置客户机流程

使用

本设计通过三个阶段的有序优化，对 Axvisor 的配置管理和启动流程进行了重要改进。这些优化旨在简化初始化配置、增强部署灵活性，并为未来交互式配置提供基础，从而整体提升系统的易用性和适应性。

优化后，原客户机配置文件中优化去掉的参数均通过读取主设备树获得，且写入axvisor内存中客户机配置结构体中，这些参数在后续使用时与优化前无区别。

以下是各阶段优化重点及影响的汇总：

阶段	优化重点	主要变化与影响
阶段一	精简配置内容	客户机配置文件内容减少，自动从主机设备树解析参数。启动命令与部署方式保持不变。
阶段二	配置文件存放位置变更	当 image_location="fs"时，客户机配置文件可与客户机镜像一样存放于文件系统中，简化了更换客户机及配置时部署流程，启动命令保持不变。
阶段三	交互式配置能力(需后续实现控制台)	为实现控制台交互式重新配置客户机参数预留了设计空间，待控制台功能实现后再作详细设计，旨在提供动态调整能力。

[hky1999]

明确 AxVisor 从哪个文件系统加载客户机配置文件
可选择复用某个 manager VM 的文件系统，也可以使用 arceos 已有的文件系统支持（但需要 arceos 支持块设备驱动）

dtb_load_addr 为何不再需要，若 default 的 dtb_load_addr 与配置文件中描述的物理内存区域冲突该如何处理

配置文件中如何描述虚拟设备（如 virtio-net 等），可以参考 libvirt 的 xml 配置

[hky1999]

设备树自动生成机制

这个设计是好的👍，是否存在已有实现？

[bullhh]

明确 AxVisor 从哪个文件系统加载客户机配置文件 可选择复用某个 manager VM 的文件系统，也可以使用 arceos 已有的文件系统支持（但需要 arceos 支持块设备驱动）

dtb_load_addr 为何不再需要，若 default 的 dtb_load_addr 与配置文件中描述的物理内存区域冲突该如何处理

配置文件中如何描述虚拟设备（如 virtio-net 等），可以参考 libvirt 的 xml 配置

多谢您的宝贵意见：

1. 若启动的客户机中包含linux，则复用linux文件系统；若客户机只有arceos，则使用arceos已有文件系统
2. 原计划在axvisor中创建一个Vec来存放生成的dtb, 目前看手动提供dtb_load_addr 也许使用起了更方便，可暂时保留，根据实际使用情况再决定是否需要
3. 配置文件中目前无计划对拟设备进行优化，需保留emu_devices = [],将进行修正

[bullhh]

设备树自动生成机制

这个设计是好的👍，是否存在已有实现？

使用vm-fdt这个库可以实现生成dtb文件，目前已有实现测试可行

[shilei-massclouds]

思路大致了解了，这样处理应该是比较好的。
但是对描述有疑问：我理解客户机配置文件应该是在宿主机或称Hypervisor上的吧？应该用不上客户机自己的文件系统吧？
比如上面回复hky关于客户机配置文件从哪加载的问题

1. 若启动的客户机中包含linux，则复用linux文件系统；若客户机只有arceos，则使用arceos已有文件系统
   我的理解是客户机配置文件用不了它们。感觉是axvisor在自己这层读客户机配置文件。

或者是有我没能理解的地方 :-)

[bullhh]

思路大致了解了，这样处理应该是比较好的。 但是对描述有疑问：我理解客户机配置文件应该是在宿主机或称Hypervisor上的吧？应该用不上客户机自己的文件系统吧？ 比如上面回复hky关于客户机配置文件从哪加载的问题

1. 若启动的客户机中包含linux，则复用linux文件系统；若客户机只有arceos，则使用arceos已有文件系统
   我的理解是客户机配置文件用不了它们。感觉是axvisor在自己这层读客户机配置文件。

或者是有我没能理解的地方 :-)

石磊老师您好，是我表达的有问题。目前我们的实现中默认系统中只有一块存储设备，该存储设备直通给客户机，所以axvisor和客户机复用了同一块存储设备并具有相同的文件系统格式。