九月底里程碑总结报告

[ZCShou]

概述

  AxVisor 开发任务的 9 月底阶段里程碑的主要目标是在飞腾派开发板上进行移植及适配，并进一步扩展及完善 AxViosr 的相关基础功能。然而，在实际执行过程中由于引入了大量其他任务，导致阶段任务并没有如期推进！

开发板

  飞腾派处理器采用飞腾嵌入式 e2000q 四核处理器，该处理器兼容 ARM V8 指令集，包含 2 个 FTC664 核和 2 个 FTC310 核，其中 FTC664 核主频可达 1.8GHz，FTC310 核主频可达 1.5GHz。主板板载 64 位 DDR4 内存，分 2G 和 4G 两个版本，支持 SD 或者 eMMC 外部存储。

阶段安排

  得益于上一个阶段中对于 ArceOS 动态平台的支持，当前阶段在飞腾派开发板（主要是 e2000q 芯片）上的移植适配要简单很多，主要以进一步修复和完善 ArceOS 动态平台为主，工作重点为 AxVisor 功能完善。

阶段目标

  针对当前 AxVisor 的开发情况，本阶段我们需要为 AxVisor 添加一些基础功能，最终实现将 AxVisor 直接部署在飞腾派开发板上的 SD 卡中，并在 AxVisor 中启动一个 Linux + 一个 ArceOS 两个客户机。为此，阶段目标制定如下：

1. 在飞腾 E2000 开发板上的 AxVisor 中以设备直通的方式至少运行一个 Linux + 一个 RTOS

2. AxViosr 支持控制台，可以在控制台中管理（增、删、改、查）客户机

3. 多个客户机有自己独立的终端供用户管理控制客户机的功能

4. AxViosr 可以正常访问存储，并从 EXT4 文件系统（主要是考虑到 Linux 客户机）中读取客户机配置文件以及客户机内核镜像

5. AxViosr 可以提供多个客户机之间通信

阶段时间

  9 月底阶段里程碑的时间阶段是 2025 年 7 月 1 号 ~ 2025 年 9 月 30 号。

阶段任务

  阶段任务使用 Github 仓库中 ISSUE 进行管理，并通过 ISUUE 的里程碑 【里程碑】9 月底在飞腾 E2000 开发板上运行 来进行进一步跟踪管理。

人员安排

  针对当前的阶段目标并结合各个开发人员的实际情况，我们对相关开发人员的工作安排如下所示。更具体的任务及负责人员参见 Github 上仓库中 ISSUE 信息即可。

序号	人员	主要工作描述
1	周 *	1. 在 ArceOS 和 AxVisor 中完善动态设备树的支持，并可以在飞腾派上启动 2. 适配 ArceOS 的 new platform 架构调整 3. 相关的其他任务
2	柏*	1. 新增客户机之前的通信功能 2. 验证之前新增的 Ext4 文件系统在飞腾派上运行情况 3. 相关的其他任务
3	杨*	1. 增加适用于飞腾派的 eMMC 驱动程序，使 AxViosr 可以访问 eMMC 中的 Ext4 文件系统 2. 添加虚拟机管理工具，以支持在控制台中对客户机增删改查 3. 相关的其他任务
4	宋*	1. 重构 axvisor 客户机加载方案 2. 相关的其他任务
5	赵*	1. 实现在飞腾派开发板上部署 AxVisor，并验证同时启动一个 Linux + 一个 ArceOS 2. 相关的其他任务

完成情况

  目前，已完成在飞腾派上的移植适配，并在飞腾派及 ROC-RK3568-PC 开发板上进行了验证。由于新引入了大量其他任务，因此，整个开发工作转为优先处理新引入的任务，导致原本计划的很多任务全部延后处理。截止 9 月 30 日，原定阶段目标仅仅完成了 60% 左右。

新增任务

  在本阶段中，针对上个阶段提到的源码仓库组织混乱的问题通过多次会议讨论进行了重点优化，重新调整了源码仓库的开发管理方式，进而引入了如下这些不在原计划中的新任务：

1. 随着新的 ArceOS 的 new platform 的架构调整，整个 AxVisor 进行了重新适配

2. 整理及完善 Crates ，并将 Crates 发布到到 crates.io

3. 搭建集成测试环境，重构了 AxVisor 的 CI 测试流程

4. 处理 deepwiki 网页转为 Markdown 格式，并支持进一步翻译、转 Word，将 Crates 文档扩展到 AxVisor、Arceos-org、StarryOS 三个组织中

5. 2025 OS 训练营相关工作

6. 在道莅基于飞腾 e2000 的 PLC 上移植及验证 AxVisor + Linux 客户机

7. 重新调相关源码的仓库的使用方式，规范了整个开发管理过程

主要任务

  本阶段在适配飞腾派开发板的同时，更多的工作转移到了新增任务的开发中，导致实际开发任务与原计划差别较大。详细的开发过程中记录以及相关问题的处理参见 Github 仓库中对应 ISSUE 或者周例会记录。以下是一些本阶段主要进行的任务及相关负责人的完成进度情况：

序号	关键任务	负责人	完成情况
1	明确了开发管理规范，明确了各个仓库分支的使用情况	赵*	100%
2	Axvisor 适配 arceos 0.2	周*	100%
3	重构 axvisor 客户机加载方案	宋*	30%
4	完善 SMMU 支持	宋*	放弃
5	新增飞腾派的 eMMC 驱动	杨*	100%
6	添加虚拟机管理工具，以支持在控制台中对客户机增删改查	杨*	30%
7	整理AxVisor相关Crates，并发布到crates.io	杨*	100%
8	提供客户机之间通信能力	柏*	50%
9	整理在飞腾派开发板的部署方案，并同时部署一个 Linux + 一个 RTOS 作为客户机	赵*、杨*	100%
10	本地测试方案搭建	柏*、赵*	100%

遗留问题

  由于目前 AxVisor 功能有限，在实际运行多个客户机时也会受到很多限制。虽然可以正常启动一个 Linux + 一个 RTOS 作为客户机，但是仍然存在以下问题（与上一阶段基本一样）：

1. 同时部署一个 Linux + 一个 RTOS 作为客户机时，最理想的情况是每个客户机一个终端，但是，由于 U-Boot 阶段只提供了一个串口，因此无法为每个客户机提供一个串口作为终端。

2. 由于目前 vGICv3 尚未实现，两个客户机时只有一个可以使用中断，因此，无法同时启动两个 Linux

   目前，中断控制器只提供给 Linux 使用，ArceOS 中不涉及任何中断！

3. 目前，AxVisor 及其依赖的 ArceOS 中，绝大多数驱动都没有添加。

   AxVisor 除了启动客户机，基本没有任何功能

后续规划

  在本阶段开发过程中，在完成基本阶段目标的同时，也发现了不少开发管理相关问题、AxVisor 功能完善相关的问题，因此，我们计划在后续阶段中首要改进开发管理相关的问题，并在飞腾派等开发板上达到相同目的的同时进一步完善 AxVisor 功能，并迭代回其他开发板！

当前现状

  目前，AxVisor 还处在开发的初级阶段，除了启动客户机基本没有其他功能。针对明年要在实际 PLC 上进行部署使用还有很多工作需要做。以下从功能、稳定性、性能三个方面列出 AxVisor 当前的状态及需要进一步开发完善的地方。

功能

优先级	需求	现状	说明	开发状态
1	CPU 虚拟化	客户机页表不支持动态等级，在大小核支持的页表等级不同时，只能支持单一类型核心的启用	开启 CPU 的硬件虚拟化支持，创建相关页表，管理内存	待完善
2	设备直通	已支持	将设备直通给客户机	已完成
3	多客户机支持	已测试 Linux + ArceOS，但是不能启动多个 Linux。已完成中断注入功能，初步实现虚拟gic，但缺少完善的虚拟中断分配等功能，缺少虚拟时钟、电源管理、块设备、串口，两个linux会发生资源争抢	至少支持 Linux + ROTS 两个客户机同时运行	待完善
4	客户机之间通信	仅 QEMU 中做了简单的验证	实际应用中大部分硬件资源会由一个客户机使用，另一个客户机对外不可见，因此需要客户机之前通信来管理另一个客户机	待完善
5	客户机管理	目前，仅仅是启动客户机，不具备任何客户机管理功能	需要允许用户对客户机增删改查	待重构
6	支持文件系统读写	初步支持，且仅支持单一类型文件系统（fat32 和 ext4不能同时存在）	支持 ext4 和 fat32 文件系统读写	需进一步完善
7	升级	不具备功能	便于设备维护	待开发
8	部署	当前不具备部署功能，前期验证全部是借用开发板的 Linux 部署环境	支持 AxVisor 独立部署到硬件设备上	待开发
9	设备模拟	进前期验证了技术可行性，没有实际在开发板上验证	存储、网络需要支持模拟	待善
10	多架构支持	支持 AArch64、x86_64 两种架构	目标是支持 AArch64、x86_64、RISC-V、LoongArch 四大主流架构	待完善

稳定性

优先级	需求	现状	说明	开发状态
1	客户机崩溃互不影响	不具备	当某个客户机崩溃后，不能影响其他客户机，并可以单独重启	待开发
2	AxVisor 可以自恢复	不具备	AxVisor 崩溃记录并自动重启，然后启动客户机	待开发
3	客户机监控记录客户机状态	不具备	AxVisor 可以提供完整的客户机监控功能	待开发

性能

优先级	需求	现状	说明	开发状态
1	文件系统性能	读写速度较慢	文件系统读写速度优化	待优化
2	AxVisor 启动	慢	AxVisor 本身需要在规定时间内启动	待优化
3	客户机启动	加载速度较慢	AxVisor 需要在规定时间内启动客户机	待优化
4	调度管理	任务调度为时间片公平调度，未支持中断唤醒，当多任务运行时，块设备或网络传输会被其他任务打断，数据包传输完后可能还在执行其他任务，不能立即开始下一个包的传输	支持多种调度策略，增加实时性	待重构

开发问题

  从目前阶段的开发情况来看，我们对于 AxVisor 的开发管理方式存在些许不足，进而导致了效率不佳、开发进度缓慢等问题。其中，比较突出的问题有如下几个：

1. 组件过渡碎片化。 作为组件化 OS，我们将一些组件单独存放的方法本身没有问题，但是在实际开发中，组件的划分合理性、组件的依赖关系等没有规范化的要求，进而导致了组件过渡碎片化，组件依赖不清。

2. 代码的审查及合并周期太长。 由于缺乏统一的代码审查及合并规范，导致很多 PR 处于长期无人处理的情况，而随着代码的迭代，PR 又得重新调整等问题

开发优化

  针对在目前阶段的开发过程中暴露出来的问题，我们需要通过一些方法来优化我们的开发管理以提高开发效率，加快开发进度。进而尽快让 AxVisor（ArceOS）达到实际应用的基本需求！

1. 制定明确的功能开发目标。 通过制定阶段目标以及年度总目标等来清晰指出我们的开发的最终目的，规范化开发过程

   1. 明确每个阶段，我们要新增那些功能

   2. 明确年终我们的完成目标，制定阶段计划

   3. 减少无关任务的引入

2. 每周或者每个阶段定时进行代码评审会议。 通过会议集中所有开发人员，统一讨论进而及时处理当前已经积压的功能更新以及 BUG 修复，以提高我们的开发效率

   1. 每周会议上评审及合并 PR

   2. 周会上讨论并解决存在的问题

3. 制定组件规范。 通过规范化的组件要求以及将组件存放到统一的位置，防止组件碎片化和依赖不清的问题

   1. 评审及规范化已有组件

   2. 实现最终组件只能从 https://crates.io/ 和我们自己的指定位置来获取

   3. 明确组件的引用方式。建议是只能通过版本号或源码仓库 TAG 来引用，防止通过分支引用时随着代码的改动而引入错误

附录

1. 开发管理规范
2. 2025年7月开发计划
3. 2025年8月开发计划
4. 2025年9月开发计划
5. 2025年10月开发计划