关于 AxVisor 现状及开发计划

[ZCShou]

AxVisor 开发计划

目标

AxVisor 下一阶段核心任务是围绕 RK3588、RDK S100、K3、飞腾派和 Intel 等真实硬件板卡，推进完善 AxVisor 的多系统混合部署能力。当前重点围绕基于 RK3588 的四足机器人和基于 RDK S100 的 PLC 样机两大平台，并且优先验证基于 RK3588 的四足机器人样机，然后是基于 RDK S100 的 PLC 样机迭代验证。

开发现状

AxVisor 已可在多个架构上启动 Linux 和 RTOS 客户机，但不少功能还在基础验证阶段。下面按模块整理现状和问题。

多架构支持

目标：各架构当前需要补代码或真机验证的路径。

优先级	工作项	状态	已完成基础	当前问题/必要性	下一步	主要平台	完成标准
P0	AArch64 EL2 路径稳固	部分实现	AArch64 是当前主线之一，已有 EL2、VGIC v3（含 GPPT）、vtimer 模拟、timer 直通、OrangePi-5-Plus/RK3588 等真实板卡配置和 board 测试	AArch64 已接近真实板卡主线，但复杂 Linux、RTOS 双域和高 DMA 外设会同时涉及 GIC/GICR、timer、Guest 设备节点裁剪和 SMMU/IOMMU，需要增加组合测试	完善 GIC/GICR、vtimer、SMMU/IOMMU（当前仅有类型占位）、Guest 设备节点裁剪和直通设备组合验证	RK3588、RDK S100、飞腾派、TAC-E400	Linux + RTOS 双域在至少两类 AArch64 板卡上可重复
P0	RISC-V H 扩展路径	部分实现	已有 RISC-V64 QEMU、riscv_vcpu（含完整 RustSBI：DBCN/TIME/HSM/SRST/PMU/RFNC）、vPLIC（pending/active bitmap + VSEIP 同步）、Sstc timer；外部中断注入经 HAL/vPLIC MMIO 路径已可在单 CPU 场景工作	vCPU 层 inject_interrupt() 为 unimplemented!()（中断仅走 HAL 绕行路径）；跨 CPU 中断注入缺少 IPI 路径（尚未实现），SMP Guest 中断注入不可用；K3 真机的 PLIC/APLIC/IMSIC/IOMMU 还没有完整验证	补齐 vCPU inject_interrupt()，实现跨 CPU IPI 路径，继续做 K3 真机验证，明确 PLIC/APLIC/IMSIC、IOMMU/PCIe 支持边界	K3、RISC-V64 QEMU	K3 或等价 RISC-V H 硬件可启动 Linux Guest 并运行用户态 smoke 测试；SMP Guest 中断注入可工作
P1	x86_64 VMX/SVM 路径	部分实现	x86_vcpu 已包含 VMX/SVM 方向代码（互斥 feature gate），测试中已有 VMX/SVM QEMU 入口；VMX 已有 EPT、MSR/IO bitmap、preemption timer；vLAPIC x2APIC MSR 模拟已完整（含 ICR IPI、ISR/TMR/IRR 跟踪、timer）；当前主要验证 NimbOS/基础用户态	x86_64 MMIO APIC_ACCESS 已有基础处理，但 vLAPIC IOAPIC broadcast 分发和 lowprio delivery 未实现（unimplemented!()）；无完整 ACPI 表解析支持（依赖 UEFI 固件或 mptable）；距离 Linux/Windows 所需的完整 ACPI、IO/APIC、时钟、块设备、网卡路径还有缺口	完善 vLAPIC IO/APIC 剩余功能（lowprio delivery）；建立 Linux bzImage/initrd/ACPI 启动链；为 Windows Guest 预留 ACPI/APIC/时钟/I/O 支持	Intel VT-x/EPT/VT-d、AMD SVM 开发机、工业 PC	x86_64 物理机或 self-hosted runner 可周期启动 NimbOS/Linux Guest，并形成 Windows Guest 可行性验证路径
P1	LoongArch64 LVZ 路径	部分实现	已有 LoongArch64 QEMU 支持和 CI/测试入口；基本 vCPU、HVC hypercall、页表映射、timer 直通已实现；inject_interrupt() 已通过 GINTC HWIS/ESTAT 实现，支持 HWI0-7 和 IPI 向量注入；当前 QEMU smoke 主要验证 AxVisor shell	handle_exception_irq() 已解码中断向量（INT_TIMER 等），但无独立虚拟中断控制器组件（中断注入直接写 GINTC/ESTAT）；QEMU smoke 仅验证 AxVisor shell 出现，无实际 Guest 运行验证	梳理 LVZ 后端支持边界，补齐虚拟中断控制器，补齐 Linux/轻量 Guest、设备路径测试	LoongArch64 QEMU	LoongArch64 可启动 Linux 或轻量 Guest，并维持 smoke 回归测试

客户机支持

目标：补齐 Guest 启动、生命周期管理、配置和故障恢复。

优先级	工作项	状态	已完成基础	当前问题/必要性	下一步	主要平台	完成标准
P0	完善不同客户机支持	部分实现	configs/vms/ 已有 ArceOS、Linux、NimbOS、FreeRTOS、Zephyr 配置（RT-Thread 还没有配置文件）；AArch64/RISC-V 已有 Linux smoke，x86_64 已有 NimbOS smoke，部分板卡已有 Linux 启动记录	RTOS 还缺标准 demo 和配置文件，x86_64 和 LoongArch64 的 Linux 链路不完整，Windows 没有启动链	按 Linux、RTOS/Unikernel、Windows 三类补启动、串口输出、rootfs、网络、存储和基础用户态验证	RK3588、RDK S100、飞腾派、K3、Intel 工业 PC	每类客户机都有能复现的启动方式、配置文件和 smoke 测试
P1	客户机生命周期管理	部分实现	shell 已支持 create/start/stop/suspend/resume/restart/delete/list/show；VM 状态机已有 Loading、Loaded、Running、Suspended、Stopping、Stopped	目前客户机能启动，但重启、暂停恢复、异常退出后的处理还不够稳，状态输出也不够方便脚本判断	补齐重复启动、暂停恢复、异常退出识别和自动恢复入口；让 VM 状态、vCPU 状态、最近退出原因能被命令行稳定查看	全部多 Guest 场景	客户机可以稳定启动、停止、重启、暂停和恢复；异常退出后有明确状态和处理方式
P1	客户机配置文件优化	部分实现	已有 VM 配置解析、Linux 镜像加载、FDT 创建/裁剪模块，也已有 QEMU、U-Boot、board 测试入口	kernel、initrd、dtb、rootfs、启动参数、串口输出和退出判断分散在不同配置和脚本里，新增客户机或新增板卡时容易重复踩坑	统一配置字段和命名方式，给 Linux、RTOS、Unikernel、Windows 分别准备模板；配置里明确镜像路径、启动参数、CPU/内存、设备、共享通道和预期输出	QEMU、U-Boot、真实板卡	新增客户机或板卡可以按模板改配置，测试脚本能直接读取关键字段
P1	Guest 故障检测	待实现	已有板级 U-Boot、board/rootfs 恢复测试基础	现有流程主要依赖外部日志和人工判断 Guest 是否异常，无法自动区分 panic、hang、非法访问和正常退出	识别 panic、hang、watchdog timeout、非法 MMIO、非法 hypercall、异常关机	Linux/AI 域、RTOS 控制域	panic、hang、非法访问和异常关机都有对应回归测试
P1	自动恢复策略	待实现	shell stop/start/restart 命令、board/rootfs 恢复流程可作为管理入口	目前恢复更多是手动操作或板级流程，缺少 VM 内建策略；Linux/AI 域异常时，实时域如何保持运行或进入安全模式尚未完善	支持 ignore、restart、shutdown dependents、进入安全模式；先补齐 VM 重新初始化，再做自动恢复策略	Linux/AI 域崩溃后重启，RTOS 域保持运行或进入安全模式	板级异常掉电后 rootfs/fsck/Guest 重启路径可自动化验证
P1	结构化 shell 输出	部分实现	已有交互式 shell 和 VM 管理命令；vm list --format json 已实现（输出 id/name/state/vcpu/memory）；vm show --full/--config/--stats 已有基础；Shell 与 VM 并发运行（vmm::start() 启动异步 vCPU 任务后返回，shell::console_init() 随即激活）	JSON 输出字段偏少（缺 vCPU 状态详情、设备列表、IRQ 统计、最近退出原因）；vm show --stats 信息量不足；shell 命令输出格式（错误码、状态变更反馈）不统一	为 vm list/show/stats 增加完整机器可读输出（vCPU 状态、设备、IRQ、内存详情）；统一错误码和输出格式	QEMU、self-hosted x86_64、真实板卡	shell 状态输出可被测试脚本完整解析
P1	日志与故障定位	部分实现	cargo xtask axvisor test 和板级串口日志可作为观测入口	现有日志能看运行输出，但缺少按 VM、vCPU、设备、IVC、测试阶段过滤和诊断命令，常见失败定位依赖人工经验	区分 hypervisor、VM、vCPU、设备、IVC、测试框架日志；支持按 VM 过滤；增加诊断命令	Guest 无输出、设备不可用、启动失败、非法访问、超时	常见启动失败和设备故障有诊断命令或日志定位说明

客户机之间通信

目标：在已有 IVC 基础上补齐 VM 间通信、配置和测试。

优先级	工作项	状态	已完成基础	当前问题/必要性	下一步	主要平台	完成标准
P0	IVC 通道完善	部分实现	已有 IVC channel 发布/订阅/取消订阅 hypercall（codes 3-6）和共享 region 管理；全局 BTreeMap<(publisher_vm_id, key), IVCChannel> 存储；subscriber 数量无硬限（BTreeMap 按需扩展）	共享区大小硬限 4096 字节（alloc_frame() 单帧，代码有 TODO "support larger shared region sizes"）；共享区是裸内存（开头 16 字节为 IVCChannelHeader，其余为纯数据），无 ring buffer、消息槽、权限标记和版本协商；通知完全依赖 Guest 主动 hypercall，没有 doorbell 或虚拟中断通知；无静态配置（仅 hypercall 动态发现）	去掉 4096 字节限制，支持多页共享区；实现 ring buffer 或消息槽协议；增加 doorbell/虚拟中断通知；增加静态 VM config 配置	Linux 管理域、RTOS 控制域	支持静态配置的单向、双向、多 subscriber 通道；通道大小可配置
P0	共享内存协议	待实现	axdevice 已有 IVC channel range allocator 和 emulated device 配置入口	当前共享区只是资源，还没有稳定的消息格式、权限标记和版本协商，Guest 双端 demo 容易各写各的协议	支持 ring buffer、固定消息槽、大块数据区、权限标记和版本字段	感知/AI 数据、控制命令、日志心跳	Linux 与 RTOS/ArceOS 双端 demo 可收发数据
P0	通知机制	待实现	hypercall、虚拟中断和共享内存基础组件已存在	如果只靠轮询或单向 hypercall，控制链路延迟和 CPU 占用不可控，不适合实时控制域和高频状态同步	支持 doorbell、虚拟中断、hypercall 或类似通知方式，避免纯轮询	低延迟控制链路	记录通知延迟和吞吐指标
P1	Guest 间虚拟网卡通信	待实现	已有 VirtIO 设备类型定义、网络设备直通配置和共享内存/虚拟中断基础	客户常用标准 TCP/IP 在 Linux、Windows、RTOS 之间通信，当前缺少虚拟网卡/虚拟交换，PLC 上位机和管理域通信会被迫走私有 IVC	提供 VM 间虚拟网卡或虚拟交换，支持 Linux/RTOS/Windows Guest 通过标准网络协议通信，补上 MAC/IP 配置、收发队列、广播/单播、限速和隔离策略	PLC 上位机、Linux 管理域、RTOS 控制域、Windows 工业软件域	多 Guest 可通过虚拟网卡互通，ping/TCP/UDP smoke、吞吐、延迟和隔离测试能进回归
P1	Guest 侧库	待实现	已有 hypercall/IVC 基础	低层 hypercall/共享内存接口对 Guest 应用不友好，Linux 用户态、内核模块和 RTOS 侧缺少统一最小 API	为 Linux 用户态、Linux 内核模块、RTOS/ArceOS 提供最小收发 API	Linux + RTOS 双域	Guest 侧 demo 不直接依赖私有内部实现
P1	通信测试集	待实现	现有 test-suit 可扩展	通信功能目前缺少吞吐、延迟、异常退出、资源释放等回归，以后改 IVC 或虚拟中断时容易破坏链路	覆盖单向、双向、多 subscriber、异常退出、通道释放、压力吞吐和延迟	QEMU 与真实板卡	通信功能进入自动化回归

实时性与调度

目标：在 Guest 能运行的基础上，补上实时延迟、干扰来源、配置方式和测试数据。

优先级	工作项	状态	已完成基础	当前问题/必要性	下一步	主要平台	完成标准
P1	vCPU pinning 与中断亲和性	部分实现	已有 vCPU task 模型和物理 CPU 绑定配置（phys_cpu_ids + phys_cpu_sets 位掩码）；已有虚拟中断后端基础（AArch64 VGIC、RISC-V vPLIC VSEIP、x86_64 vLAPIC ICR）；ArceOS task 支持设置 CPU 亲和性	现有绑定功能还没有上升为实时域、管理域、普通域的配置语义，也缺少 IRQ 亲和性和冲突校验，实时隔离效果难以复现	声明实时 vCPU、管理 vCPU、普通 vCPU；关键 IRQ 固定到实时域核心	RK3588/S100 实时控制域	实时样例输出 RTOS jitter、IRQ 和调度延迟统计
P1	时间同步	部分实现	已有虚拟 timer、host time API 和多架构 vCPU 后端基础	Linux 与 RTOS 混合部署需要统一时间基准，目前缺少跨 Guest 校准路径和误差报告，日志、控制周期和故障诊断难以对齐	通过 hypercall 提供 Guest 时间查询与校准接口，误差报告写入 vm stats	Linux + RTOS 双域	双域时间误差在毫秒级以内，有校准测试数据
P1	性能观测与运行指标	待实现	VM/vCPU 运行循环已有基础	没有 per-VM latency、VM exit、IRQ、jitter 等计数器时，实时性只能靠主观观察，也无法设自动化回归阈值	在 vCPU 运行循环中添加 per-VM VM exit 次数、中断次数、调度延迟计数器，通过 vm stats 命令和 shell JSON 输出暴露	全部性能测试	vm stats 输出 VM exit、IRQ、调度延迟等数值，可被测试脚本采集
P2	调度策略与 overcommit	待实现	ArceOS task 调度作为 vCPU 承载层	vCPU 当前作为 task 运行，但缺少实时域固定核、Linux 域配额、非实时 overcommit 等策略，资源紧张场景下行为不可预测	实时 VM 固定核或高优先级；Linux VM 使用配额、可抢占或普通调度；非实时 VM 支持 overcommit	Intel 非实时 VM、Linux 用户态吞吐	overcommit 有统计、限额和降级策略报告

测试与交付

目标：每个开发计划有可重复验证路径，最终形成可交付版本。

优先级	工作项	状态	已完成基础	当前问题/必要性	下一步	主要平台	完成标准
P0	分层测试体系	部分实现	已有 test-suit/axvisor 的 QEMU、SVM QEMU、board smoke/build 用例；quick-start 和 xtask 侧已有 QEMU/U-Boot/board 运行流程	现有测试能覆盖基础启动，但 smoke、normal、stress、fault 边界不清，新增功能很难对应到稳定回归等级	建立 smoke、normal、stress、fault 分层测试，并把 U-Boot/board 流程进一步固化进回归入口	全部 P0 功能	每个 P0 功能至少有 smoke 和 normal 测试
P0	故障与长稳测试	待实现	已有 board/rootfs 流程和测试入口	多系统部署在长时间运行、异常重启、设备复位和文件系统恢复上容易暴露问题，当前这些情况还没有系统回归	加入 stress、fault injection、reboot loop、device hot reset、fsck recovery	板级和多 Guest 长稳	隔离、恢复、长稳都有回归用例
P1	性能基准	待实现	已有 QEMU/board 运行入口	没有统一基准时，VirtIO、虚拟网卡、IVC、调度和中断优化只能凭单次结果判断，无法跨版本比较	建立启动耗时、VM exit 频率、virtio 吞吐、中断延迟、RTOS jitter、共享通信延迟指标	QEMU、Intel、RK3588/S100	性能结果可记录和对比
P1	板级测试固化	部分实现	已有 U-Boot、board、guest 镜像准备和 rootfs 流程	板级测试依赖串口、U-Boot、镜像和 rootfs 状态，若记录和流程不固化，真实板卡问题很难复现和交接	真实板卡保留 U-Boot、串口日志、rootfs 恢复、异常复位和长稳测试记录	RK3588、S100、飞腾派、K3	交付候选配置有可执行板级测试说明
P1	版本与文档交付	待实现	已有 board/vm config、guest 镜像准备和测试入口	当前配置、镜像和测试说明还没有按 dev/basic-release/delivery 分层，外部试用和内部开发容易使用不同说明	建立 dev、basic-release、delivery 三类配置和镜像仓库索引；每个功能域提供配置说明、运行命令、测试用例和已知限制	交付候选版本	交付候选配置通过 QEMU 自动化测试
P2	远端管理与可视化	待实现	shell 和串口管理基础已存在	真实板卡交付和演示通常不能只依赖串口人工操作，需要 host 工具或可视化界面快速查看 VM、设备和告警状态	先实现串口/host 工具读取状态，再扩展 Web/PC 端可视化	RK3588、S100、飞腾派交付演示	远端工具可查看 VM 和设备状态

开发计划

后续开发优先验证基于 RK3588 的四足机器人样机，然后是基于 RDK S100 的 PLC 样机。两条线都先做 Linux + RT-Thread 双客户机，Linux 作为业务、管理和上层应用域，RT-Thread 作为实时控制域。

M1：双客户机基础

目标：Linux + RT-Thread 在 RK3588 和 RDK S100 上稳定启动，后面的样机都基于这套基础。

开发计划	主要开发内容	依赖	完成标准
RK3588 双客户机启动	准备 RK3588 上的 Linux + RT-Thread 配置，明确 CPU、内存、串口、timer、中断和基础外设归属	RK3588 板级配置、Linux/RT-Thread 镜像	RK3588 可稳定启动 Linux 和 RT-Thread，两个客户机都有串口输出和基础 smoke
RDK S100 双客户机启动	准备 RDK S100 上的 Linux + RT-Thread 配置，先跑通最小可用启动链	RDK S100 板级配置、Linux/RT-Thread 镜像	RDK S100 可稳定启动 Linux 和 RT-Thread，启动流程可以复现
客户机配置文件整理	把两个样机需要的 kernel、dtb、rootfs、RT-Thread 镜像、CPU/内存、设备和共享通道写进清晰的配置模板	现有 VM config、board config、U-Boot/QEMU 流程	新增或调整样机配置时，不需要到处改脚本
基础生命周期命令	保证 start、stop、restart、suspend、resume、list、show 对双客户机场景可用	AxVisor shell、VM 状态机	Linux 和 RT-Thread 可以被单独启动、停止、重启和查看状态

M2：双客户机通信

目标：Linux 和 RT-Thread 之间同时支持共享内存和基于虚拟网卡的两种通信方式，能传控制命令、状态、日志和心跳。

开发计划	主要开发内容	依赖	完成标准
共享内存通道	支持 Linux 和 RT-Thread 之间可配置的共享内存通道，先满足单向和双向通信	IVC、共享内存配置、虚拟中断基础	两个客户机可以稳定收发小消息和状态数据
消息格式	定义简单固定的消息头、命令类型、长度、序号和返回状态，避免两边 demo 各写一套格式	共享内存通道	控制命令、状态上报、日志和心跳使用同一套格式
通知机制	在共享内存基础上补通知方式，优先使用虚拟中断或 hypercall，减少纯轮询	中断注入、hypercall、RT-Thread 侧适配	Linux 发命令后 RT-Thread 能及时收到，RT-Thread 状态变化也能通知 Linux
双端 demo	提供 Linux 用户态 demo 和 RT-Thread demo，覆盖命令下发、状态返回、心跳和异常断开	消息格式、通知机制	两个样机都能跑同一套通信 smoke
虚拟网卡通信	在 Linux 和 RT-Thread 之间建立基于虚拟网卡的网络链路，支持 TCP/UDP 通信	虚拟网卡/虚拟交换、VirtIO 后端、Guest 网络协议栈	Linux 和 RT-Thread 可通过虚拟网卡互相 ping 和收发数据
网络应用层协议	在虚拟网卡链路上实现应用层通信协议，复用任务二的消息格式定义	虚拟网卡通信、消息格式	控制命令、状态上报、心跳通过网络协议也能走通
网络通信 smoke	验证虚拟网卡链路下的吞吐、延迟和异常恢复	网络应用层协议	网络通信有基础性能数据

M3：RK3588 四足机器人样机

目标：围绕四足机器人场景，把 Linux 侧的上层业务和 RT-Thread 侧的实时控制串起来。

开发计划	主要开发内容	依赖	完成标准
机器人双域配置	Linux 负责感知、规划、日志和管理，RT-Thread 负责控制周期、执行器指令和实时状态	M1 双客户机基础	RK3588 上有面向四足机器人的 Linux + RT-Thread 配置
控制链路 demo	Linux 下发步态模式、速度、停止等命令，RT-Thread 返回控制周期、状态和错误码	M2 双客户机通信	可演示 Linux 到 RT-Thread 的控制闭环
实时性观测	记录 RT-Thread 控制周期抖动、通信延迟、Linux 负载下的影响	通信 demo、RT-Thread timer	有一组可复现的延迟和抖动数据
异常处理	验证 Linux 重启、通信中断、RT-Thread 心跳丢失时的处理方式	生命周期命令、故障检测	异常发生后状态可见，RT-Thread 可进入安全处理流程

M4：RDK S100 PLC 样机

目标：围绕 PLC 样机场景，把 Linux 侧的配置、监控和网络接入，与 RT-Thread 侧的控制任务和 I/O 状态同步打通。

开发计划	主要开发内容	依赖	完成标准
PLC 双域配置	Linux 负责配置、监控、日志和网络接入，RT-Thread 负责周期控制和现场 I/O 状态	M1 双客户机基础	RDK S100 上有面向 PLC 的 Linux + RT-Thread 配置
PLC 通信 demo	Linux 下发运行、停止、参数更新等命令，RT-Thread 返回周期状态、I/O 状态和报警信息	M2 双客户机通信	可演示 PLC 基础控制和状态上报
管理侧接口	Linux 侧提供简单命令行或服务入口，方便查看 RT-Thread 状态和发送控制命令	PLC 通信 demo	现场调试不需要直接进入 RT-Thread
长期稳定和掉电恢复	验证反复启动、异常复位、rootfs 检查、RT-Thread 心跳恢复	board 测试、rootfs 恢复流程	PLC 样机有基本长稳记录和恢复流程

人员安排

人员	职责
@ZR233	负责架构优化完善相关
@ZCShou	负责仓库优化、配套设施完善等
@YanLien	负责 AxVisor 多客户机声明周期管理
@Josen-B	负责客户机之间通信机制的实现
@bullhh	继续推进 Starry 在 RK3588 四足机器人板卡上的完善