2026年8月开发计划

[ZCShou]

开发计划

1. 计划说明

本月围绕由固件直接引导的 Type 1 AxVisor 推进开发，以 RK3588 机器人为主要集成与验证平台，形成 Linux/StarryOS 富功能域与 Zephyr/ArceOS 实时、轻量域协同运行的环境。

初步时间计划

里程碑	时间	并行任务及负责人	集成关系	退出条件
M1 仓库主线收敛	8 月 14 日	T0-1 @ZR233；T0-2 @pengzechen	lifecycle、VGIC 与 guest/virtio-net 并行收敛	lifecycle、VGIC、guest/virtio-net 的依赖与测试入口明确
M2 并行基础能力可用	8 月 17 日	AX-1 基础 @YanLien；AX-2 @Josen-B；AX-4 基础 @ZR233；AX-5 基础 @ZCShou、@YanLien	客户机、IVC、调度程序和控制框架分别开发，完成后进入跨任务联调	客户机配置、IVC、调度测试入口及测试控制流程可用于跨任务联调
M3 SG2002 闭环交付	8 月 20 日	P1-7 @bullhh	与 AX-6 复用摄像头、推理、底盘和机械臂能力	自主找球和夹球流程完整并能够连续运行
M4 AxVisor 核心能力	8 月 26 日	AX-1 @YanLien；AX-2 @Josen-B；AX-3 @elliott10；AX-4 @ZR233	AX-3 使用 AX-1 板级环境，AX-1～AX-4 的结果逐步接入 AX-5	四类客户机与多客户机环境完成；IVC、128 实例和调度切换达到计划指标
M5 RK3588 完整演示	8 月 31 日	AX-5 @ZCShou、@YanLien；AX-6、P1-7 @bullhh	AX-6 接入 AX-1 客户机、AX-2 IVC 和 AX-5 控制面	控制面接入各项用例，端到端机器人环境完成并可安全运行

2. 完善 AxVisor

AX-1～AX-5 由不同负责人从 8 月 3 日并行推进。AX-6 同期开展摄像头、推理、实时控制和执行反馈的客户机内工作，8 月中旬在 AX-1 客户机环境、AX-2 IVC 和 AX-5 控制面具备基础能力后进入跨客户机联调。

AX-1：多客户机适配、资源分区与混合部署

整合来源： plan/axvisor.md P0-2、P0-3、P0-4、P0-10
时间： 2026.8.3～2026.8.21
开发主要负责人： @YanLien

缺失内容

AxVisor 已具备其他 RK3588 板卡和 QEMU 上的 Linux、Zephyr、ArceOS 基础，也能装载多个 VM 配置，但尚未形成 RK3588 机器人客户机环境、跨 VM 全局资源所有权模型和多客户机并行运行的实体板证据。

开发任务

1. 完成 RK3588 机器人平台的 board config、U-Boot 启动流程、客户机目录和实体板测试入口，核对 CPU、RAM、GIC、timer、UART、存储、网络及设备依赖。
2. 建立跨 VM CPU、RAM、共享内存、MMIO、IRQ、设备和 DMA/IOMMU 所有权表，在 VM 创建前拒绝冲突配置，并同步裁剪自动生成或用户提供的 guest DTB。
3. 建立 Linux、StarryOS、Zephyr、ArceOS 客户机配置，分别面向富功能、实时和轻量任务。
4. 配置 Linux、Zephyr、ArceOS 三种不同属性客户机同时运行，并为 StarryOS 富功能客户机保留可替换、可组合配置。
5. 将客户机启动、资源冲突和三 VM 并行用例接入实体板测试框架，保存 shell、串口和结果文件。

完成标准

• Linux、StarryOS、Zephyr、ArceOS 均有 RK3588 机器人平台配置、镜像和测试入口；
• Linux、Zephyr、ArceOS 三种不同属性客户机同时正确启动、运行并执行命令；
• StarryOS 可作为富功能客户机启动，并能与 Zephyr 或 ArceOS 组成机器人场景配置；
• 客户机不能访问未分配的 CPU、内存或设备，资源冲突在 VM 创建前被拒绝；本项不额外增加运行时长或重复轮次指标。

AX-2：IVC 跨客户机通信

整合来源： plan/axvisor.md P0-5
时间： 2026.8.3～2026.8.17
开发主要负责人： @Josen-B @elliott10

缺失内容

现有 IVC publish/subscribe 通道上限为 4 KiB，超过上限的请求会被截断，无法完成 256KB、512KB、1MB、10MB 的共享内存通信测试，也不能支撑机器人视觉域向实时域传输控制消息。

开发任务

1. 将 IVC 改造为控制区和多页数据区，支持页对齐数据区、生产/消费索引、状态和错误返回。
2. 明确通道所有者、共享内存授权、满/空、断连和 VM 删除后的资源回收语义。
3. 在 Linux/StarryOS 与 Zephyr/ArceOS 客户机实现通信端点和 benchmark，记录每次读写的数据长度与耗时。
4. 执行四种数据长度测试，并为 AX-6 的检测结果、控制命令和执行反馈提供稳定传输通道。

完成标准

• 256KB、512KB、1MB、10MB 四种情况分别测试 100 次；
• 每种长度的平均读速率和平均写速率均不低于1Gbps；
• 保存每次读写的数据长度和耗时，并按统一方法计算平均读写速率；
• 本项不额外增加断连、重连和异常退出的测试轮次指标。

• 对应性能效率指标值: 内核间通信速率不低于1Gbps

AX-3：128 个轻量内核实例基于vCPU超分运行

整合来源： plan/axvisor.md P0-6、P0-13
时间： 2026.8.3～2026.8.26
开发主要负责人： @elliott10

缺失内容

AxVisor 当前没有在 RK3588 的 8 个物理 CPU 上运行 128 个单 vCPU 轻量内核及获取输出结果。

开发任务

1. 前置背景：AxVisor 支持了Virtio-net 的后端设备模拟， 轻量客户机ArceOS支持了网络。
2. 检查 VM、vCPU、task、页表、IRQ、设备和日志的每实例成本，只修改实际阻塞 128 个单 vCPU VM 的容量限制。
3. 实现普通 vCPU 在 8 个物理 CPU 上的时间复用，并保持 VM 状态、心跳和网络端点可查询。
4. 可以执行 128 个实例的vCPU模拟 、运行访问、ping 和 clean。

完成标准

• 启动 128 个轻量内核实例。 在满足网络前置背景=中，启动网络，设置地址为 10.0.0.1～10.0.0.128，管理端配置为 10.0.0.254/24；
• 测试脚本能够网络 ping 通全部 128 个实例；
• 执行 clean 移除 128 个实例后，这些地址均不可网络 ping；

• 对应功能性指标值：支持128个内核扩展

AX-4：调度切换与中断时延

整合来源： plan/axvisor.md P0-3、P0-4、P0-9
时间： 2026.8.3～2026.8.26
开发主要负责人： @ZR233

缺失内容

AxVisor 尚未在 RK3588 机器人平台完成任务调度切换测试，也没有把多客户机并行场景中的Zephyr中断时延输出与软件 cycle counter 结果形成统一证据。

开发任务

1. 在 VM客户机实现主、副任务切换程序，使用硬件寄存器记录每次调度切换前后的时钟周期数。
2. 每组执行百万次切换并输出最小、平均、最大时钟周期数，共执行 10 组。
3. 在 Linux、Zephyr、ArceOS 多客户机并行环境中，同时保存 Linux 调度负载、ArceOS 调度切换和 Zephyr 中断时延结果。
4. 对达到或超过调度门槛的路径进行定位和优化，不为 Zephyr 中断时延增加计划外的数值阈值。

完成标准

• 调度切换执行 10 组、每组百万次，10/10 组最大值均 <800 cycles；
• 每组保存最小、平均、最大时钟周期数；
• Linux、Zephyr、ArceOS 并行时，Zephyr 在 shell 输出中断时延结果；

AX-5：VM 管理、监控与测试控制面

整合来源： plan/axvisor.md P0-10、P0-12
时间： 2026.8.3～2026.8.28
开发主要负责人： @ZCShou（控制面与测试框架）、@YanLien（客户机接入）

缺失内容

AxVisor 已有 bare-metal shell、VM manager 和 lifecycle 命令，但配置、启动、查询、test、clean 步骤尚未形成统一流程，也不能统一支撑多客户机、IVC、128 实例、调度和场景测试。

开发任务

1. 统一 AxVisor bare-metal manager、shell 或 xtask 的测试入口，覆盖 VM 配置、启动和 run/test/clean 操作。
2. 提供 VM 配置、创建、启动、状态查询、停止、删除和 clean 操作，并保留对应 shell 或串口结果。
3. 接入 AX-1 的四类客户机和多客户机并行用例、AX-2 的 IVC 用例、AX-3 的 128 实例用例及 AX-4 的调度用例。
4. 建立各项测试与实体板测试项的对应关系，保存每项测试的输入、步骤、预期结果和原始证据。

完成标准

• 控制面能完成计划所需的 VM 配置、启动、查询、test 和 clean 操作；
• 能执行三客户机并行及 128 个轻量内核实例的 run、test、clean；
• 各项测试均有对应的实体板测试项、输入、步骤、预期结果和证据文件定义；
• 不将 JSON schema、重试轮次、重连时间或故障注入次数列为本计划验收指标。

AX-6：RK3588 机器人场景端到端闭环

整合来源： plan/axvisor.md P0-7、P0-8、P0-11、P1-1～P1-6、P1-8
时间： 2026.8.3～2026.8.31（8.3～8.16 分域开发，8.17～8.31 跨域集成）
开发主要负责人： @bullhh

缺失内容

当前直接运行 StarryOS 的机器人程序已经具备 UVC 采集、RKNPU/YOLOv8 识别、追球视觉伺服、底盘运动、机械臂逆运动学与 P 控制、抓取失败重试、找桶和放球等能力，并能够执行“寻球→追球→抓取→找桶→放球→回到寻球”的完整捡球流程。AX-6 的目标不是只在 AxVisor 上运行一个目标检测示例，而是以单独运行 StarryOS 时的完整捡球功能为对齐基线，在 AxVisor 多客户机环境中复现同等功能闭环。

迁移时需要拆分原来集中在 StarryOS 单系统内的图像识别和运动控制：Linux/StarryOS 非实时客户机负责摄像头采集、图像预处理、RKNPU 推理、网球与桶识别、目标跟踪和高层任务状态；Zephyr/ArceOS 实时客户机负责底盘速度控制、转向与停车、机械臂轨迹与抓取/释放、限位、急停和执行器安全。两类客户机通过 IVC 传递检测结果、动作意图、控制目标和执行反馈，由 AxVisor 提供 CPU、内存、中断、设备及 DMA/IOMMU 隔离，形成“采集→推理→IVC→RTOS→执行器→反馈”的完整闭环。

功能拆分

层次	从单独运行 StarryOS 的程序中拆出的能力	在 AxVisor 环境中的职责
Linux/StarryOS 非实时客户机	UVC 采集、图像解码与预处理、RKNN YOLOv8、网球/桶识别、目标跟踪、捡球任务状态机	识别网球和桶，决定寻球、追球、抓取、找桶、放球等高层阶段，向实时域发送目标位置和动作意图
IVC 通信	原进程内检测结果、运动请求和函数返回	携带帧 ID、时间戳、序号、检测结果、动作意图和有效期，并返回底盘、机械臂、故障及动作完成状态
Zephyr/ArceOS 实时客户机	追球视觉伺服中的运动执行、底盘控制、机械臂逆运动学与 P 控制、抓取/释放及安全处理	将目标和动作意图转换为确定性的底盘、舵机和机械臂控制，执行限位、急停、失联停止并返回结果
AxVisor	原单系统直接拥有的 CPU、内存、中断和设备	隔离两类客户机，调度 vCPU，路由中断，管理 IVC，并按所有权分配摄像头、NPU、GPIO/PWM/UART 和 DMA/IOMMU 资源

架构图

开发任务

1. 固定当前单独运行 StarryOS 的 build/tennis、模型、摄像头、底盘、机械臂、校准文件、抓取参数和完整捡球流程，作为拆分前的功能对照基线。
2. 将 UVC 采集、图像解码与预处理、RKNPU/YOLOv8 推理、网球/桶识别、目标跟踪和高层捡球任务状态迁移到 Linux/StarryOS 非实时客户机。
3. 将底盘速度与转向控制、停车、机械臂逆运动学与 P 控制、抓取/释放、限位和急停迁移到 Zephyr/ArceOS 实时客户机。
4. 将原程序内部的检测结果和运动控制调用改为 AX-2 IVC 消息，传递帧 ID、时间戳、目标位置、动作意图、有效期和错误状态；过期、乱序或损坏消息不能触发执行器动作。
5. 固定摄像头、NPU、网络、GPIO/PWM/UART、底盘和机械臂的客户机所有权，以及 MMIO、IRQ、clock/reset/power-domain 和 DMA/IOMMU 依赖；非实时客户机不得直接操作安全关键执行器。
6. 将底盘、机械臂、故障和动作完成状态经 IVC 返回非实时客户机，使任务状态机能够推进“寻球→追球→抓取→找桶→放球→回到寻球”。
7. 验证抓取失败重试、目标丢失、IVC 断链、单客户机异常、设备错误和控制域失联路径，异常时执行器进入安全状态且其他客户机保持隔离。
8. 将完整捡球环境接入 AX-5 控制面，保存各客户机 shell/串口、NPU 输出、IVC 消息、控制命令、执行反馈及完整流程结果。

完成标准

• Linux/StarryOS 富功能域、Zephyr/ArceOS 实时或轻量域在 AxVisor 上组成可启动、可管理的机器人环境；
• 非实时客户机完成摄像头采集、网球/桶识别、目标跟踪和高层任务决策，实时客户机完成底盘、机械臂、抓取/释放和安全控制，二者不越权访问对方设备；
• 在 AxVisor 环境中无人干预完成“寻球→追球→抓取→找桶→放球→回到寻球”，功能结果与单独运行 StarryOS 的完整捡球流程对齐；
• 每个动作意图均能关联到实时域的执行结果或故障反馈，抓取失败可回到重试或继续寻球状态；
• 过期、乱序或损坏消息不触发动作，IVC 或实时控制域失联时执行器进入安全状态；本项不增加已有对比材料未规定的端到端时延、运行时长和故障注入次数阈值。

基于已有测试方案 整理推荐的AxVisor测试用例

测试用例	指标值	指标类型
测试用例1：瑞芯微 RK3588 国产化智能芯片适配	指标1: 基于瑞芯微 RK 国产化智能芯片	可移植性
测试用例2：验证 AxVisor 混合部署VM虚拟机支持 NPU 驱动	指标2: 支持 2 NPU + 8 CPU 核心的异构硬件	可移植性
测试用例3：NPU 支持 YOLO 算法推理	指标2: 支持 2 NPU + 8 CPU 核心的异构硬件	可移植性
测试用例4：Linux 虚拟机功能测试	指标3: 支持不少于 3 种内核	功能性
测试用例5：Linux 虚拟机 cyclictest 测试	指标3: 支持不少于 3 种内核	功能性
测试用例6：LMBench 测试	指标3: 支持不少于 3 种内核	功能性
测试用例7：IOZone 测试	指标3: 支持不少于 3 种内核	功能性
测试用例8：Zephyr 虚拟机功能测试	指标3: 支持不少于 3 种内核	功能性
测试用例9：ArceOS 虚拟机功能测试	指标3: 支持不少于 3 种内核	功能性
测试用例10：三内核并行运行时 Linux 功能测试	指标4: 支持 3 种以上不同属性内核同时运行	功能性
测试用例11：三内核并行运行时 ArceOS 功能测试	指标4: 支持 3 种以上不同属性内核同时运行	功能性
测试用例12：三内核并行运行时 Zephyr 功能测试	指标4: 支持 3 种以上不同属性内核同时运行	功能性
测试用例13：三内核并行运行性能测试	指标4: 支持 3 种以上不同属性内核同时运行	功能性
测试用例14：基于vCPU的内核可扩展测试	指标5: 支持 128 个内核扩展	功能性
测试用例15：移除基于vCPU的扩展内核测试	指标5: 支持 128 个内核扩展	功能性
测试用例16：共享内存中不同数据长度读写速率测试	指标6: 内核间通信速率不低于 1 Gbps	性能效率
测试用例17：任务调度切换开销测试	指标7: 任务调度切换开销小于 800 个时钟周期	性能效率
测试用例18：通过网卡直通给VM虚拟机验证支持设备直通	指标8: 支持设备直通	其他功能项
测试用例19：基于vCPU模拟验证支持vCPU模拟访问	指标9: 支持设备模拟访问	其他功能项
测试用例20：基于virtio-net虚拟网络设备模拟验证支持virtio-net设备模拟访问	指标9: 支持设备模拟访问	其他功能项

3. 完善 Starry

这部分工作主要是收尾当前直接在 SG2002 机器人上运行 Starry 实现捡球的功能！

P1-7：SG2002 整车自主追球抓取闭环

时间： 2026.8.3～2026.8.7
开发主要负责人： @bullhh

缺失内容

摄像头、TPU、底盘、机械臂和自主追球状态机已经分别具备基础能力，但尚未完成“发现网球—转向—接近—停车—抓取—复位”的连续实机闭环，也没有稳定参数和失败恢复记录。

开发任务

1. 串通摄像头采集、TPU 推理、目标选择、底盘控制和机械臂抓取。
2. 标定检测框中心、面积阈值、转向速度、接近速度、稳定帧数和抓取距离。
3. 处理目标丢失、误检、画面抖动、抓取失败、串口断连和动作超时。
4. 增加每阶段状态、耗时、检测结果、底盘命令和机械臂结果日志。
5. 完成多位置、多距离和不同光照下的连续抓球测试。
6. 归档模型、动态库、akars、启动命令、参数文件和部署步骤。

完成标准

• 自主模式可连续完成寻球、接近和抓取；
• 自主找球和夹球流程完整，连续运行过程及异常均保留日志；
• 目标丢失或组件异常时底盘停止，机械臂保持安全姿态；
• 形成一套可从干净 rootfs 复现的部署与演示流程。

4. 完善 TGOSKITS 仓库

这部分工作主要是在开发过程中，随时处理 TGOSKITS 仓库收到的各种 PR，问题修复等！

T0-1：收敛 AxVM 生命周期、调度与虚拟中断主线

时间： 2026.8.3～2026.8.14
开发主要负责人： @ZR233
协作人： @YoungCIoud、@aptacc2421、@YanLien、@manbo1234

缺失内容

当前 VM lifecycle、vCPU task、runtime ownership、guest device、虚拟 IRQ routing、VGIC 和 PSCI/SMP guest 启停由多组 open PR 同时修改。接口、状态所有权和测试依赖尚未完全收敛，存在重复修改、合入顺序不清和单 PR 通过但组合路径失败的风险。

开发任务

1. 梳理 PR #1775、PR #1715、PR #1717、PR #1718、PR #1803、PR #1829、PR #1828 和 PR #1692 的依赖关系与合入顺序。
2. 固定 VM 状态转换、vCPU 启停、pause/resume/stop 请求与完成语义，以及 task、timer、IRQ route 和 device runtime 的唯一所有者。
3. 统一完整 INTID、LR 满载、pending/active、EOI/DIR、GICv2 target mask、PSCI CPU_ON/OFF 和系统复位的错误处理与回收路径。
4. 增加 AArch64 GICv2/GICv3、单核/SMP guest、设备 IRQ 注入和 VM 重启组合测试。
5. 同步 lifecycle 和组件文档，删除仍描述旧 init()/boot()/run_vcpu() 模型的内容。

完成标准

• 形成并评审一份明确的 PR 依赖与合入顺序；
• VM lifecycle、device runtime 和 virtual IRQ routing 不再存在两套公开状态源；
• AArch64 单核及 SMP guest 的启动、停止、重启和 SPI 注入测试通过；
• 代码、测试和文档对 VM 状态与错误语义的描述一致。

T0-2：完善 AxVisor guest、虚拟网络与可复现启动路径

时间： 2026.8.3～2026.8.17
开发主要负责人： @pengzechen
协作人： @YoungCIoud、@aptacc2421

缺失内容

FreeRTOS guest、virtio-net、新虚拟网络设备、x86_64 HLT/timer 唤醒和 OVMF 启动能力分散在不同 PR 中；当前测试尚不能稳定证明 guest 已进入目标启动阶段、网络设备完成收发并且 VM 停止后资源被正确回收。

开发任务

1. 收敛 PR #1697、PR #1804、PR #1769、PR #1802 和 PR #1607 的配置、镜像和测试入口。
2. 为 FreeRTOS/Linux guest 增加 console、virtio-net 初始化、收发包和关闭/重启 smoke。
3. 固定 OVMF DEBUG profile、固件版本、装载窗口和 guest 串口阶段标记，避免以宿主的 VM boot success 代替 guest 启动结果。
4. 统一 cargo xtask、镜像注册表、QEMU 脚本和文档中的命令与路径。
5. 检查网络队列、中断、timer 和 vCPU task 在 guest 停止后的释放顺序。

完成标准

• FreeRTOS/Linux guest 至少各有一个可复现启动配置；
• virtio-net 可完成基本收发，重启 VM 后队列和 IRQ 可重新建立；
• OVMF 测试能区分 SEC、PEI、DXE、BDS 或 guest OS 阶段；
• 文档中的命令可在干净环境直接复现。

T0-3：完善 Starry 进程、内存与图形应用回归

时间： 2026.8.3～2026.8.21
开发主要负责人： @Lfan-ke
协作人： @ZR233

缺失内容

Starry 的进程退出资源顺序和 RLIMIT_AS 语义正在修复；OpenGL ES、OpenGL、Vulkan 和 WebGPU 的 compute/render 用例数量增加，但尚需统一构建依赖、结果标记、超时、日志和 normal/stress 分组，避免形成只能人工判断的孤立用例。

开发任务

1. 完成 PR #1800 和 PR #1797 的真实系统回归，覆盖 zombie 发布前资源释放、vfork/SysV SHM 和 mmap/mremap 地址空间上限。
2. 收敛 PR #1814、PR #1816、PR #1818 和 PR #1820 的 rootfs 依赖、运行命令和结果格式。
3. 为图形用例分别记录 API、语言、后端、渲染/计算输出、耗时和失败阶段。
4. 将快速 smoke 与大规模 carpet 分组，控制普通 PR CI 的运行时间。
5. 增加失败正则、超时清理和产物归档，保证故意破坏依赖或输出时用例能够失败。

完成标准

• 进程退出和 RLIMIT_AS 用例在 riscv64 QEMU 路径稳定通过；
• 四类图形 API 的 render carpet 均有机器可判定结果；
• 测试失败可定位到 rootfs、运行时、图形后端或结果校验阶段；
• 普通 CI 与 stress/夜间测试的边界明确。

T0-4：整理仓库文档、发布与板级驱动修复

时间： 2026.8.10～2026.8.28
开发主要负责人： @ZCShou
协作人： @Josen-B、@yydawx

缺失内容

架构文档仍需随目录和组件边界调整；release PR、RK3588/SG2002 板级修复及视频、串口等驱动改动缺少统一的合入检查和复现记录，容易出现代码已修改但文档、板卡配置或测试入口未同步的情况。

开发任务

1. 完成 PR #1792 的架构文档目录调整，并检查内部链接、组件索引和 AxVisor 设备说明。
2. 跟踪 PR #1764 的版本、crate publish 顺序和 release 门禁。
3. 收敛 PR #1726 和 PR #1714 的板级配置、驱动验证和复现日志。
4. 对本月合入的 board、guest、driver 和 test 配置执行文档同步检查。
5. 每周清理重点 PR 的冲突、失效测试和未分配 reviewer。

完成标准

• 架构文档链接和组件索引检查通过；
• release 流程能够完成 dry-run，并能定位版本或发布顺序错误；
• 板级修复至少保留构建命令、目标板/架构、运行日志和成功标记；
• 重点 PR 不因长期冲突或无人 review 阻塞。

[elliott10]

Update: 根据已有的测试方案进一步进行了修改，其中主要添加了基于已有测试方案整理推荐的AxVisor测试用例

[Josen-B]

客户机通信进展

✅基于共享内存的客户机通信已基本实现，并合入主线

• feat(axvisor): Implement inter-VM communication (IVC) demo and protocol enhancements #1834
  涉及ci中测试用例 AxVisor / QEMU aarch64 · IVC

✅基于此方案，实现一个sdk，提供用户态方便使用的ivc接口，还有镜像构建脚本等

• https://github.com/rcore-os/ivc-sdk

✅实现zephyr和starry的客户机通信demo，通过后与@bullhh 结合在捡球机器人上进行调试优化

✅测试用例16：共享内存中不同数据长度读写速率测试

对应推荐 AxVisor 测试用例

测试用例	指标值	指标类型
测试用例16：共享内存中不同数据长度读写速率测试	指标6: 内核间通信速率不低于 1 Gbps	性能效率

✅：已完成，✨：正在进行

[bullhh]

StarryOS + Zephyr 双客户机捡球进展

目前已在 Orange Pi 5 Plus RK3588 上实现 AxVisor 同时运行 StarryOS 和 Zephyr：

• StarryOS 负责 UVC 摄像头采集、RKNN YOLOv8 网球/桶识别；
• StarryOS 通过 IVC 将识别结果发送给 Zephyr；
• Zephyr 负责底盘、机械臂和失联安全停车；
• 两台客户机使用独立物理 CPU 和内存，可同时持续运行和切换控制台。

当前真实识别和通信约为 20 FPS：

运行中发现的 AxVisor 全局卡死已经定位为 vCPU 唤醒通知的反向锁顺序问题。修复后已完成超过10分钟完整压力测试和约28分钟持续运行，原来几十秒内出现的卡死未再复现。修复尚待整理为独立 PR。

对应推荐 AxVisor 测试用例

当前实现能够覆盖或部分覆盖 Discussion #1832 中以下测试：

测试用例	覆盖情况
用例1：RK3588 国产化智能芯片适配	已覆盖：在 Orange Pi 5 Plus 实体板启动 AxVisor 和两台客户机
用例2：混合部署 VM 支持 NPU 驱动	部分覆盖：StarryOS 使用 NPU 时，Zephyr 可并行运行
用例3：NPU 支持 YOLO 算法推理	已覆盖：StarryOS Guest 运行真实 RKNN YOLOv8，约20 FPS
用例8：Zephyr 虚拟机功能测试	已覆盖：启动、Shell、定时器、WFI、IVC、UART6和机器人控制正常
用例16：共享内存通信测试	部分覆盖：已验证48字节控制消息长期稳定传输；尚未完成大数据和1 Gbps测试
用例18：设备直通	补充覆盖：已验证UART6 MMIO、IRQ和FDT直通，但不能替代指定的网卡直通测试
用例19：vCPU及模拟设备访问	部分覆盖：两台客户机通过vCPU运行，虚拟控制台、定时器和IVC设备可用

[YanLien]

多客户机启动进展

目前已在 AArch64 QEMU 上实现 AxVisor 同时启动和运行两台 Linux 客户机：

• 两台客户机拥有独立的 vCPU、内存和虚拟设备；
• 启动阶段可以同时查看两台客户机的完整行输出；
• 进入交互模式后，可以在两台客户机及 AxVisor Shell 之间切换；
• 后台客户机的输出会独立缓存，切换后可以回放，不再出现多台客户机日志按字节交错的问题。

多客户机控制台支持已通过 PR #1912 (#1912) 合入。该 PR 完成了双 VM QEMU 启动、命令输入、前后台切换、后台日志回放和返回 AxVisor 控制台的验证。

客户机配置、Machine 资源规划、设备运行时和控制台所有权等设计，已经通过 PR #2103 (#2103) 拆分整理为独立文档，为后续多客户机资源分区和设备扩展提供统一说明。

目前正在本地完善 virtio-blk 客户机块设备：

• 支持通过客户机 TOML 配置镜像路径、容量和文件系统；
• 新建空镜像默认格式化为 ext4，未指定容量时使用 64 MiB 最小容量；
• 已有非空镜像不会重新格式化；
• file backend 使用异步写回和 flush 流程；
• AArch64、RISC-V 保留兼容的固定 MMIO/IRQ，x86_64、LoongArch 由 Machine 资源规划自动分配；
• 正在补充 AxVisor 为 ArceOS 客户机提供独立 ext4 virtio-blk 磁盘的端到端测试。

该 virtio-blk 实现目前仍是本地未提交修改，尚待完成验证并整理为独立 PR。

对应推荐 AxVisor 测试用例

当前实现能够覆盖或部分覆盖 Discussion #1832 中以下测试：

测试用例	覆盖情况
用例4：Linux 虚拟机功能测试	部分覆盖：已验证两台 Linux 客户机并行启动、运行和控制台交互
用例10：三内核并行运行时 Linux 功能测试	部分覆盖：已完成双 Linux 客户机并行运行，尚未完成 Linux、Zephyr、ArceOS 三种内核实体板联合验证
用例11：三内核并行运行时 ArceOS 功能测试	正在推进：本地 virtio-blk 用例用于验证 ArceOS 客户机独立磁盘和文件读写
用例12：三内核并行运行时 Zephyr 功能测试	尚未由上述 PR 单独覆盖
用例13：三内核并行运行性能测试	尚未覆盖：当前工作解决启动稳定性和控制台交互，尚无三客户机性能数据
用例19：基于 vCPU 模拟验证设备访问	部分覆盖：多客户机通过 vCPU 运行，虚拟控制台、定时器和 WFI 唤醒可用；virtio-blk 模拟设备正在本地验证

[ZCShou]

2026-08-24 ~ 2026-08-28 进度记录

1. StarryOS 与 Zephyr 的拆分运行已经完成基础验证。两个系统目前可以在 Axvisor 下独立启动和运行，基础的镜像加载、资源划分及 Guest 运行链路已经走通。跨系统通信还没有形成完整、可复现的闭环，后续需要继续打通共享内存或 virtio-net 数据通路、通知中断及双向通信测试。@bullhh @Josen-B

2. 多 vCPU 支持仍处于实验和优化阶段。PR #2131 已在 QEMU AArch64 的 2 个物理 CPU 上验证多个单 vCPU Guest 分时运行，初步证明了 vCPU 超额分配路径可行。不过，这还不等同于单个 Guest 内的 SMP 多 vCPU 支持已经完善。相关 PR 尚未合并，当前还在优化时间片控制、vCPU 状态切换、调度公平性、唤醒和中断投递，并补充压力与长期运行验证。@elliott10

3. 调度切换与中断时延仍在持续完善。PR #1775 正在重构调度器与运行时的所有权边界，仓库也已加入 StarryOS 唤醒和调度时延基准。现阶段重点是继续收敛远程唤醒、IPI、NOHZ、定时器、上下文切换和虚拟中断路径，缩短关中断临界区，并在 SMP 和高负载场景下持续观察 P95、P99 及最大时延。@ZR233

[elliott10]

”轻量内核实例基于vCPU超分运行“
基于OrangePi 物理板子的8 个物理虚拟成多vCPU 支持运行了 24 个 VM的测试用例
请见PR：test-suit(axvisor): run 24 virtio-net peers on all eight OrangePi cores
#2498

[ZCShou]

详见 9 月份开发计划 #2373