实习开发计划

[YoungCIoud]

七月

本月主要完成四架构共享的中断基础设施。

第一阶段：共享资源与 runtime 递送通道

• 为 Resource 增加 IrqLine { line: u32, trigger: InterruptTriggerMode }，使用 BTreeMap 索引建立独占 IRQ line 注册，检测同一设备重复声明和不同设备占用同一 line，bundle 注册失败时回滚已登记的 IRQ line。（feat(axdevice): register exclusive IRQ line resources #1630）
• 新增 VirtualInterruptId(u32) 和携带 trigger mode 的 PendingVcpuInterrupt，避免 x86 u8 vector 限制扩散到其他架构。（feat(axvm): add virtual interrupt model types and per-vCPU dispatch queue #1661）
• 新增 per-vCPU VcpuIrqDispatcher（入队/出队/reset）和 VcpuInterruptQueue（FIFO、vCPU 隔离），enqueue() 不在锁内调用 wake/IPI/外部回调。（feat(axvm): add virtual interrupt model types and per-vCPU dispatch queue #1661）
• 新增 VmInterruptSender，持有 Weak<AxVM>，每次发送时查找当前 runtime、不缓存 dispatcher；新增 dispatch_vcpu_interrupt() 按”入队 → notify → host IPI”顺序递送。（feat(axvm): add VmInterruptSender and integrate dispatcher into VmRuntimeHandle #1679）
• vCPU run loop 在进入 guest 前 drain 新 dispatcher 并调用 ArchOps::inject_vcpu_interrupt()；迁移期继续 drain 旧 pending_interrupts，双队列并存。（feat(axvm): add VmInterruptSender and integrate dispatcher into VmRuntimeHandle #1679）
• VM stop/reset/start 后 sender 只能发现当前 runtime，不能向旧 dispatcher 入队；runtime 不存在或 vCPU 未注册时返回明确错误。

第二阶段：RISC-V 基线验证

• 验证 vPLIC pending、claim、complete 和 secondary vCPU IPI。

8 月

从八月开始进行 xVisor x86_64 Guest UEFI 的支持工作。

第一阶段：诊断基础 — 固件入口验证

目标：建立一条可复现、可归因的诊断链，让每次 UEFI 启动都能确定"OVMF 走到了哪一步"。

1. 固定 OVMF profile
2. Guest COM1 阶段 observer：利用已有的 COM1 串口设备，在字节流中识别 OVMF 阶段标记
3. 设备访问 trace
4. OBMF 固件装载日志
5. OVMF entry 测试用例

第二阶段：PCI 与启动盘 — virtio-pci

目标：OVMF 通过 PCI 枚举发现 virtio-blk 设备，读取 ESP 并进入 UEFI Shell 或加载 EFI 应用。

本阶段已完成 PCI core 的，剩下的是加入 virtio-blk 设备和准备 GPT/ESP/rootfs 镜像。

9月

当前 dev 已经打通了“x86 UEFI guest 的固件交接和 Linux 早期用户态” 即直接通过 fw_cfg（提供kernel、initramfs等等） 进入Linux内核，但还没有打通标准的“OVMF 从 guest 磁盘 ESP 启动 Linux”。本月的目标就是“OVMF 从 guest 磁盘 ESP 启动 Linux”。

所以一条硬主链路是：

1. virtio-blk-pci
2. guest 磁盘接入
3. GPT/ESP/rootfs 镜像
4. OVMF 读盘并启动 EFI 程序
5. Linux 挂载 rootfs

disk.img（包含GPT、ESP、rootfs、 BOOTX64.EFI） 能够和 virtio-blk-pci 并行开发，但是问题是 disk.img 先完成后 AxVisor 中没有地方能够消费这个镜像，只能通过普通 QEMU + OVMF 做独立预验证。

预计最难的点就是接入一块是接入一个能够同时被 OVMF 和 Linux 使用的 virtio-blk-pci guest 设备。

等这条链路梳理通后，就是补强：VARS、E820、SMBIOS 和 SMP。

[YoungCIoud]

7月13-7月19 进度

首先是中断注入架构的重构，合入了 #pr1630：校验跨设备所有权，并把注册流程收敛为“完整校验 → 统一写入索引 → 加入设备列表。

但是此次合并和后续的重构计划于 #pr1612 有较大冲突（待此pr合并后需要基于新的IRQ所有权模型重新设计）。

于是接下来转向了 UEFI 的支持工作，并且特别注意绕开了可能会依赖 #pr1612 的任务。详细见 #issue1646

此任务尝试做的是开发独立的 x86_64-unknown-uefi 应用 probe.efi 探测 guest os 启动的过程，验证 AxVisor UEFI 计划当前需要、且能够通过标准 UEFI 应用观察到的平台契约。

目前的成果是已经实现独立的 x86_64-unknown-uefi、no_std UEFI application，能够在原生 OVMF/QEMU 上运行（还未集成入 AxVisor），并实施十六项检查（涵盖配置输入、UEFI核心环境、ACPI平台描述、PCI与存储设备、UEFI Runtime Services），以下为运行截图：

现在还需要进行一些删减：目前修改了CI，除了在 CI diff 中新增原生 probe job 外，还有调整 AxVisor 的 AMD SVM/Intel VMX self-hosted 条目和把原来的 hosted SVM 位置换成了 native probe 等不必要的修改。 probe job 的目的是为了保证：probe.efi 始终可以为 UEFI target 编译、probe 能在原生 OVMF/QEMU 环境通过完整矩阵。

[YoungCIoud]

7月20-7月26 进度

中断 sender/dispatcher 通道 （PR #1679 待合入）

• 在 intr/sender 增加 VmInterruptSender：
  • 只持有 Weak<AxVM>，每次发送重新选择当前 runtime，不缓存会在 stop/reset/start 后失效的 dispatcher。
  • 对 VM 已销毁、状态不接受中断、runtime 不存在和目标 vCPU 未注册返回明确错误。
• 将 dispatcher 接入 VmRuntimeHandle，固定 enqueue → notify_all → host IPI 顺序。
• 在 vCPU run loop 中 drain 新 dispatcher，并通过 trigger-aware ArchOps::inject_vcpu_interrupt() 完成最终注入。
• 保留旧 pending_interrupts 消费路径，迁移期先旧后新，尚无 Router producer 时不改变 Guest 行为。
• 修正 trigger 兼容边界：
  • x86 edge/level 映射到 VMX/SVM backend 的 level_triggered。
  • AArch64、RISC-V、LoongArch 明确由 Router/controller 消费 trigger，最终架构注入不静默改变语义。

建立 UEFI 的可诊断基线

os/axvisor/scripts/setup_qemu.sh 会搜索发行版安装的任意 OVMF 文件，这无法保证不同环境访问相同的平台资源。于是固定了一套 x86_64 Guest OVMF DEBUG profile。选择了 edk2-stable202605，构建参数为：

architecture: X64
target: DEBUG
toolchain: GCC
platform: OvmfPkg/OvmfPkgX64.dsc
defines:
  FD_SIZE_4MB
  DEBUG_ON_SERIAL_PORT
  BUILD_SHELL=TRUE
  SMM_REQUIRE=FALSE
  SECURE_BOOT_ENABLE=FALSE
  TPM2_ENABLE=FALSE
  NETWORK_ENABLE=FALSE
  SDCARD_ENABLE=FALSE
  CC_MEASUREMENT_ENABLE=FALSE

增加了对固件的校验：校验来源、构建开关、大小、地址、SHA-256、combined 关系、reset-vector 覆盖和阶段 marker。

增加 VMX/SVM OVMF entry 诊断用例和相应文档；成功条件不再使用宿主侧 VM boot success 冒充 Guest UEFI 成功。

AArch64 中断 Router 设计

• 3A：无损 INTID、ICH/TDIR 字段和可恢复 LR error。
• 3B：VGIC SPI line/pending/active 状态与固定 route。
• 3C：per-vCPU ICH context、fold/refill、两种 EOImode、TDIR/maintenance。
• 3D：typed route 配置、controller 共享所有权与两阶段初始化。
• 3E：ArmInterruptRouter → sender kick → target refill。
• 3F：synthetic SPI device、EL1 SMP2 Guest 与 QEMU 端到端验证。

[YoungCIoud]

7月27-8月2日进度

本周概述

本周主要完成了三项工作：

1. 合入 PR feat(axvm): add VmInterruptSender and integrate dispatcher into VmRuntimeHandle #1679，贯通 sender/dispatcher/run-loop 完整中断投递通道，共享基础设施阶段收尾。
2. 创建 PR fix(arm-vcpu): preserve full virtual interrupt IDs #1715 和 feat(axvm): implement AArch64 VGIC SPI delivery foundation #1829，从底层 INTID/ICH/LR 修复到 per-vCPU ICH context、VGIC SPI 状态机、delivery port 和 maintenance PPI 的完整投递基础。
3. 创建 PR feat(axvisor): add reproducible OVMF debug profile #1802，为 x86_64 Guest UEFI 建立可复现的 OVMF DEBUG 基线。

此外合入了一个工具链改进 PR #1827，使 Claude Code 能正确加载 AGENTS.md 项目规范：

1. 中断 sender/dispatcher 通道收尾

详情见上周，本周推动合入

2. AArch64 VGIC SPI 投递基础

• 无损 INTID 与可恢复 LR error：ArmVirtualIntId(u32) 替代 u8 截断，typed LR 编解码与槽位规划，LR 满载返回错误而非 panic，修正 IDBITS 宽度、软件 EOI overlay 和 GICv2 Group/EOI 配置反转。
• per-vCPU ICH context 与 pin 收敛：IchCapabilityProfile 按 pCPU 发现 GIC 虚拟化能力，per-pCPU registry 校验异构兼容性；bind()/unbind() 保存恢复 HCR/VMCR/APR/LR，重构 run_vcpu() 收敛 bind/run/unbind 到同一 CpuPin scope。
• VGIC SPI 状态机：durable truth 覆盖 trigger、enabled、pending_latch、active、inflight、deactivation，pulse/set_level/fold/reconcile/refill 状态转换，锁内不调外部回调。
• delivery port 与 LR refill：每次 guest entry 前 fold→reconcile→refill；edge 重复 pulse 合并为 ActivePending，level deactivate 后重投、lower 后停止；区分 EOImode=0/1，TDIR trap→DIR 跨 vCPU 返回 owner hint。
• maintenance PPI：从 FDT 发现并注册 GICv3 maintenance PPI，host-lifetime per-CPU handler。

3. Guest UEFI P0 可复现固件基线

• 固定 EDK2 edk2-stable202605 / 固定 commit，X64、DEBUG、4 MiB、COM1 debug、内置 Shell，关闭 SMM/Secure Boot/TPM/network。
• 固定产物布局：OVMF_CODE.fd（0x37c000）、OVMF_VARS.fd（0x84000）、OVMF.fd（0x400000）、manifest.toml。
• 增加受限 flat TOML manifest parser 与 bundle 校验（来源、构建开关、大小、地址、SHA-256、combined 关系、reset-vector 覆盖）。
• 本地 unverified 固件必须显式启用 AXVISOR_X86_64_UEFI_ALLOW_UNVERIFIED=1。
• 固定 CODE 装载契约：bios_load_addr = 0xffc84000、大小 0x37c000、entry_point = 0xfffffff0。
• 增加 Guest COM1 SEC 诊断 matcher，通过 SEC phase marker 区分"固件进入 SEC"和"只启动了 VM"。

[YoungCIoud]

8月3-8月9日进度

本周概述

本周主线是 x86_64 Guest UEFI 支持：验证当前启动链路的 PR #1931 已合入 dev。同时正在进行增加 PCI 只读数据盘的工作，目标是为 direct-boot Linux guest 提供标准的只读 modern virtio-blk PCI 数据盘。

1. x86 OVMF ACPI 验证合入 (#1931)

现在的 dev 已经具备了启动 linux 的能力，通过 fw-cfg 将内核镜像、initrd、命令行参数直接注入虚拟机内存，ovmf 充当 bootloader 的角色。这个工作只补充验证与说明：

1. 记录固件的路径、大小和SHA-256哈希值。
2. 增加和 VMX 对称的 SVM 测试用例。
3. 完善 ACPI 的测试（table-loader 的 allocate、pointer、checksum 命令逐条断言）
4. 更新测试文档和 x86 UEFI 调试说明

PCI 只读数据盘（正在进行）

标准 PC UEFI 会执行完整的 PCI 总线枚举，发现磁盘控制器，构建设备路径，所以就需要增加一个标准 PCI 块设备。

阉割

为了降低实现的复杂度，目前的设计中阉割了一些 feature/协议，但是 Linux/OVMF 看到的是一块完全标准的只读盘,只是没做那些启动场景用不到的可选特性。

• 无flush / discard / write-zeroes 语义。目前只读，若后面需要可写需要单独设计。
• 无 legacy/transitional，只支持 Modern 模式。
• 只保留现有的传统 PIO config，不加 MMIO config。
• 省略 packed virtqueue。虽然提升吞吐量但是协议复杂。
• 无间接描述符feature。
• 无 event index 中断抑制优化。
• 不支持队列重置（queue 复用优化）。
• 不支持多队列 feature。
• 未设计异步后端。
• 单 endpoint，也就是说还没有注册表、跨节点协议。

[YoungCIoud]

8月10-8月16进度

本周概述

本周主线从验证当前 x86_64 Guest UEFI 启动链路转向只读 PCI 数据盘的实现：

1. 合入 PR ci(axvisor): run ovmf-acpi-svm on self-hosted AMD CI #1959，将 ovmf-acpi-svm 接入 self-hosted AMD CI，补齐 SVM 后端嵌套 OVMF/ACPI 路径的持续回归覆盖。
2. 合入 PR fix(axvirtio-common): harden shared virtqueue against untrusted guests #1984，完成 axvirtio-common 共享 virtqueue 面向不可信 guest 的加固（issue 加固 axvirtio-common 中面向不可信 guest 的共享 virtqueue #1979），经过三轮 bot review 后并入 dev。
3. 创建 draft PR feat(virtio): add synchronized VirtIO block PCI ramdisk #2070，落地只读 virtio-blk-pci 数据盘的产品实现与 E2E 用例，并在真机 KVM 验证中定位到 x86_vcpu NPF/EPT 通用 MMIO 解码缺失，已作为独立前置项列出。

1. PR #1959 — ovmf-acpi-svm 接入 AMD CI（已合入）

完成内容

上周 PR #1931 把 ovmf-acpi-svm 用例合入 dev，但 CI 中只跑了 ovmf-acpi-vmx，SVM 后端缺少嵌套 OVMF 路径的持续回归覆盖。这个 PR 直接仿照现有 ovmf-acpi-vmx job，在 self-hosted AMD/KVM runner 上运行 ovmf-acpi-svm，并同步文档中的 CI 任务名、VMX/SVM 宿主要求与用例边界。

2. PR #1984 — 共享 virtqueue 加固（已合入）

背景与问题

PR #1935 使用axvirtio-common::VirtioQueue ，PR #2070 实现了一个检查更严格的 VirtioQueue，为了解决两个队列的共存问题就有了本 PR。axvirtio-common::VirtioQueue 是本仓库所有 virtio 设备模型共用的唯一 virtqueue 实现（消费者为 axvirtio-net 和 axvirtio-blk）。面向不可信 guest 时存在四个缺口（issue #1979）：

1. descriptor_chain 链长边界 off-by-one（>= size），与 follow_chain 的 > size 不一致，合法全索引链被拒；
2. 三个环地址只查非零，不做对齐、溢出和互不重叠的布局校验；
3. MMIO QUEUE_READY 可在未验证布局上直接生效；
4. VirtioError 无法表达布局为何无效，transport 无法据此决策。

完成内容

• queue/descriptor.rs：统一链长边界为 > size，合法全索引链两条路径行为一致。
• queue/mod.rs：新增 validate_layout() / validate_layout_with_memory()，校验三环地址非零、对齐、addr + size*elem 不溢出、三区域互不重叠；环区域大小无条件包含 EVENT_IDX footer，footer 别名或越界布局被拒绝；新增 faulted 状态（Acquire/Release），运行期 ring/descriptor 校验失败即置位，pop/complete 及 5 条 guest-data 路径在 faulted 下拒绝且不写 guest 内存，reset() 清除；非 _with_memory 入口委托 _with_memory 孪生，读失败同样 latch fault；is_valid() 内部增加 validate_layout() 调用。
• mmio/state.rs：QUEUE_READY 写成为「三地址非零 + scoped guest memory 布局校验」的单一强制点；新增 mmio_write_with_memory，axvisor 生产路径可在真实 scoped memory 下正常置 ready。
• error.rs：新增 RingMisaligned / RingOverlap / InvalidRingLayout / QueueFaulted 四变体，区分「运行期故障需 reset」与「正常预配置状态」。
• axvirtio-net：TX/RX drain 前检查 is_faulted()，faulted 时停止服务并告警，不再把预读失败吞成空队列；mmio_write_with_memory 透传 scoped guest memory。
• axvirtio-blk：同步接入 mmio_write_with_memory，修复 scoped-memory ready 校验遗漏，避免 NoGuestMemoryAccessor 下队列无法 ready 的回归。
• 额外收紧：QUEUE_NUM 在 ring 地址已编程后被拒绝。

3. PR #2070 — 只读 virtio-blk-pci 数据盘（draft，阻塞中）

背景与目标

为 x86_64 guest 增加一块 BDF 00:03.0、4 KiB BAR0、modern non-transitional、单 queue、INTx 的只读 virtio-blk PCI 数据盘，让 direct-boot Linux 枚举设备、只读挂载 ext4 并读取 identity 文件，最终命中 AXVISOR_X86_PCI_BLOCK_PASSED + identity=axvisor-readonly-data-v1。

完成内容（15 commits，58 files，+8105/−579）

实现上，我的设计对照参考了 Cloud-Hypervisor 的实现。

1. axdevice：x86 PCI 函数表驱动化，新增一个 MMIO PCI 函数槽位；
2. axvirtio-blk：将 block 请求/配置从 MMIO transport 解耦，供 PCI transport 复用；
3. axdevice：新增只读 virtio-blk PCI 函数，对齐 virtio 1.x 的 capability/common-config 语义（driver_feature 只写 + mask、config_generation 机制、queue_size 初始 0）；
4. axvm：plan x86 virtio-blk-pci 磁盘，MP PCI 路由对齐 resolved endpoint；
5. axvisor + build.rs：加载不可变 virtio block 镜像，编译期生成、运行时只读挂载；
6. axbuild：生成 8 MiB raw ext4 确定性镜像，内含 /axvisor/identity.txt = axvisor-readonly-data-v1；
7. axbuild + test-suit：新增 qemu-pci-block E2E case（svm/vmx），guest 走 enable_bios=false + boot_protocol="direct"。

使用效果

例如：客户机配置里写：

[[devices.virtual]]
id = "readonly-data-disk"
model = "virtio-blk-pci"
backend = "file"
path = "${workspace}/tmp/axbuild/axvisor/qemu-pci-block/axvisor-readonly-data.ext4"
read_only = true

AxVisor 就能把对应镜像文件冻结成只读盘，固化进自己的镜像里，启动 Linux 客户机时，把它作为一块标准 PCI 块设备交给客户机使用。

真机 E2E 验证与阻塞

测试覆盖了镜像生成、设备建模、资源规划、固件路由、客户机实际读写整条链路。

在 AMD Ryzen 9 7940H（SVM）+ Docker/KVM 上，SVM/VMX 两后端结论一致：

• 外层 Axvisor 以 uefi=true + to_bin=true 启动，SVM/VMX 均成功开启硬件虚拟化；
• guest Linux direct-boot 正常，cmdline 正确携带 axvisor.block_case=pci；
• ACPI DSDT/APIC/FACP/SPCR 齐全，PCI0._CRS 正确发布 bus 0 和 4 KiB window；
• PCI 枚举成功：pci 0000:00:03.0: [1af4:1042] class 0x018000，BAR0 分配成功；
• virtio-pci 驱动绑定成功：enabling device (0000 -> 0002)。

随后 guest 写 BAR0 device_status（0x80000014，byte 写）时进入无限 NPF/EPT 循环。根因：x86_vcpu 的 SVM/VMX MMIO 解码器只认 LAPIC/IOAPIC 地址且只支持 dword 宽度，virtio-blk-pci BAR0 是 x86 上第一个通用 MMIO 设备，byte/word 写未被解码，RIP 不前进导致死循环。该问题 SVM/VMX 复现一致。

当前状态

PR 保持 draft，已在 PR body 中记录阻塞与完整 E2E 分析；计划另开 feat(x86_vcpu): decode generic device MMIO of arbitrary width on NPF/EPT 修复前置项，合入后再继续完成 #2070 的只读挂载、identity 读取与 INTx completion 增长验证。

合入后的下一步

#2070 合入后，下一步是复用同一块只读 virtio-blk-pci 设备，把它接入 OVMF 启动路径：让 guest UEFI 通过 VirtioBlkDxe 枚举到该盘，并尝试从它启动 Linux，使这条链路从 direct-boot 数据盘升级为 OVMF 可见/可启动的 virtio-blk PCI 磁盘。

4. 下周重点

• 提交并推动 feat(x86_vcpu): decode generic device MMIO of arbitrary width on NPF/EPT 前置 PR，解除 PR feat(virtio): add synchronized VirtIO block PCI ramdisk #2070 阻塞。
• 继续 feat(virtio): add synchronized VirtIO block PCI ramdisk #2070 E2E：修复后验证 guest 只读挂载 ext4、读取 identity、写保护生效、INTx completion 增长，最终命中 AXVISOR_X86_PCI_BLOCK_PASSED + identity=axvisor-readonly-data-v1。

[YoungCIoud]

0817—0823进度

本周概述

1. 修复 PR feat(virtio): add synchronized VirtIO block PCI ramdisk #2070 的前置阻塞项
2. 根据 @ZR233 老师的建议重构 virtio-blk-pci 数据盘。

1. PR #2082（已合入）

解决的问题

Guest 系统访问设备的 MMIO 区域（Bar0）时，硬件没法直接完成这次内存读写，CPU 会VM Exit到 Axvisor。但是之前没有普通设备MMIO 解码的逻辑。本 PR 就是给解码器补上设备 MMIO 访问的指令解码。

当前状态

已合入 dev。

2. PR #2070 — 只读 virtio-blk-pci 数据盘

当前状态

第一轮实现后， @ZR233 提出了复用性问题，需要调整各层的边界并给出了修复意见。这周主要根据修复意见重构，目前已经重构完成，在排查 bug 和整理 commit 的阶段。

合入后的下一步

#2070 合入后，下一步是复用同一块只读 virtio-blk-pci 设备，把它接入 OVMF 启动路径：让 guest UEFI 通过 VirtioBlkDxe 枚举到该盘，并尝试从它启动 Linux，使这条链路从 direct-boot 数据盘升级为 OVMF 可见/可启动的 virtio-blk PCI 磁盘。可写后端、实时文件后端等能力不在本 PR 范围内，留待后续独立推进。

3. 下周重点

• 推动 feat(virtio): add synchronized VirtIO block PCI ramdisk #2070 合入，修复问题，整理commit

[YoungCIoud]

0823-0830 进度

本周概述

1. 合入 PCI foundation feat(axvisor): add generic vPCI foundation with x86 PCI enumeration #2197，初步搭建起通用的 PCI core 和 PCI 设备枚举路径。
2. 实现了 virtio-blk 块设备，支持同步写。

PR #2197

已经合入，目前PCI 设备能够通过统一的 DeviceGraph、planner注册、获取资源、x86 架构下能够通过 CF8/CFC 这个机制访问配置。Linux Guest 已经能够通过 lspci 正确枚举 pci 设备和 Bar 资源。

ramdisk virtio pci 块设备

现在的状况是已经在本地实现：能够在通用 vPCI 上接入 modern VirtIO Block，补齐了 2197 pci core 中缺失的 pci capability、BEM/DMA和INTx 中断路径这些。并且支持同步ramdisk 的 read、write、flush 语义。目前剩余同时阻塞在端到端验证。

完成这个块设备的合入后，下面几项工作可以同步进行：

1. 继续补充 feat(axvm): add generic virtual PCI and VirtIO block PCI support #2184 剩余的 MSI/MSI-X 这些项目；
2. disk.img 镜像资产，并测试验证通过磁盘启动Linux；

目前的阻塞项

在实际的端到端验证下，会出现两个卡点导致超时，现在正在尝试找原因并尝试优化：

[    0.000000] APIC: Switch to symmetric I/O mode setup <----卡点1，能卡 6-7 min。
[   97.201000] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
[   97.327000] tsc: Unable to calibrate against PIT
[   98.029000] tsc: HPET/PMTIMER calibration failed
[   98.782000] tsc: Marking TSC unstable due to could not calculate TSC khz
[   99.557000] Calibrating delay loop... 1176.57 BogoMIPS (lpj=588288)
......
[  106.841000] x86/fpu: xstate_offset[6]:  896, xstate_sizes[6]:  512
[  106.854000] x86/fpu: xstate_offset[7]: 1408, xstate_sizes[7]: 1024
[  106.966000] x86/fpu: Enabled xstate features 0xe7, context size is 2432 bytes, using 'compacted' format. <---- 卡点2，能卡3-4分钟。

ai 之外

首先编码都是由 AI 来编写的，我自己做的工作能够概括为让 AI 写什么和如何让AI写对。

• 做什么：第一件事是我和 @baitwo02 参照 @ZR233 的意见，梳理通了 feat(axdevice): add typed virtual PCI and AArch64 ECAM support #2169 和 feat(virtio): add synchronized VirtIO block PCI ramdisk #2070 两个功能有较大重叠 PR 的合入顺序。然后依据“要合入的功能必须要有消费者验证”这一点，依据 lspci 能够验证的功能，划分了 PCI foundation 的范围。然后依据 x86_64 Guest UEFI 这条主线，划定了下一步就是要做一个 Linux、OVMF 都可识别、可读取的 virtio pci 块设备。
• 如何做对：我需要有一份详细的设计文档来约束 AI 编码，在 AI 生成的初版设计文档上，着重从规定修增并发死锁这些容易在运行时出问题的地方。同时复核AI查出的问题。最后在本机进行端到端验证收集accpet/reject 证据。

总的来说就是 AI 驾驶员

[YoungCIoud]

关于端到端验证的卡点，已经排除了 PM Timer/PIT 频率错误、IRQ0 amplification、VINTR retry loop 及 PIC handler 本身过慢等因素。又观察到在 CI 和 Linux 本机可以比较顺利的通过，我将原因锁定为本地 wsl 带来的嵌套虚拟化放大了 AxVisor 当前 timer delivery path 的成本。

[YoungCIoud]

0831-0906 进度

本周概述

PR #2070 ramdisk virtio pci 块设备

识别了之前本地端到端测试超时的问题，wsl 环境嵌套虚拟化导致运行速度严重下降。之后的解决办法就是远端跑CI。

读写测试全部通过，也就是说至此有了一块 guest 能识别到并且读写的块设备。但需要说明的是这里的写功能只支持针对 ramdisk 后端的同步写。

详细设计记录与 #2070 更新的附件中。

启动盘验证

依靠上面所实现的 PCI 块设备，本周还开始尝试将它当作启动盘用 UEFI 起 Guest。

我在本地制作了一个简易的镜像，看起来大概是这个样子：

/                                    (FAT32 根目录)
├── EFI/
│   └── BOOT/
│       └── BOOTX64.EFI              # GRUB 的 UEFI 可执行文件（removable 默认路径）
│
└── boot/
    ├── grub/
    │   ├── grub.cfg                 # GRUB 配置文件
    │   └── x86_64-efi/              # GRUB 模块（如 normal.mod、linux.mod 等）
    │       └── ...（模块文件）
    │
    ├── vmlinuz                      # Linux 内核
    └── initramfs                    # initramfs（cpio.gz 格式）

整个镜像只有一个 FAT32 分区作为EFI系统分区，包含了所有启动需要的文件。大小只用 256 MiB，仅作为我在验证能否顺利地起guest。

但是其实并不那么顺利还是有问题。

目前已经跑进了 Linux，但是端到端测试不通过，时限30min依旧超时。正在排查原因

[YoungCIoud]

0907-0913 进度

本周概述：

本周最主要的成果就是跑通了UEFI 起 x86 Linux guest 的 CI 测试（本地WSL环境有问题会超时失败）

临时测试资产的制作

1. 创建 256 MiB 的稀疏文件：truncate -s 256M /tmp/uefi-guest.img
2. 创建 GPT 分区表 parted -s /tmp/uefi-guest.img mklabel gpt
3. 创建唯一一个分区并规定类型和起始位置 parted -s /tmp/uefi-guest.img mkpart ESP fat32 1MiB 100%
4. 设置为 EFI System Partition 类型 parted -s /tmp/uefi-guest.img set 1 esp on
5. 需要找到一个空闲的 loop 设备，并将镜像挂载为块设备，同时保存找到的loop名，供后续使用：LOOP=$(losetup --find --show --partscan /tmp/uefi-guest.img
6. 在第一个分区上创建 FAT32 文件系统 mkfs.fat -F 32 -n EFI "${LOOP}p1"
7. 挂载 ESP mkdir -p /tmp/uefi-esp mount "${LOOP}p1" /tmp/uefi-esp
8. 安装 GRUB UEFI 引导器 grub-install --target=x86_64-efi --efi-directory=/tmp/uefi-esp --boot-directory=/tmp/uefi-esp/boot --removable --no-nvram --recheck
9. 复制内核 cp path_of_linux /tmp/uefi-esp/boot/vmlinuz，这里我选用的 linux 其实就是 tgoskits/tmp/axbuild/images/qemu-x86_64/linux/linux-qemu
10. 跟上面一样复制 initramfs，这里的 initramfs 也是选用的仓库中现有的initramfs-x86_64.cpio.gz
11. 编辑 grub.config：

set timeout=0
set default=0

menuentry "Linux from virtio disk" {
    linux /boot/vmlinuz console=ttyS0 rdinit=/init loglevel=7
    initrd /boot/initramfs
}

12. 收尾 umount /tmp/uefi-esp losetup -d "$LOOP"

制作完成之后我将其压缩后放在：assets/uefi-guest.img.gz

测试逻辑

guest 配置包含：

boot_protocol = "uefi"
boot_source = "pci-disk"

[[devices.virtual]]
model = "virtio-blk"
transport = "pci"
backend = "ramdisk"
image_path = "/uefi/uefi-guest.img"
read_only = true

对于 boot_source = "pci-disk"， x86_64 的 boot 代码只加在 guest ovmf 和提供 ACPI、VirtIO PCI 设备，而不像之前一样提供 kernel/initramfs。

后续起 guest 必须经过: OVMF、VirtIO PCI 磁盘、BOOTX64.EFI、GRUB、Linux 这样一条链路。

最后当匹配到 sh: can't access tty; job control turned off 后，认为 UEFI 固件到 Linux 用户态的完整链路被完整验证。

通过的日志

• vmx
• svm

[YoungCIoud]

0921-0927 进度

本周概述

本周的工作来自 PR #2275。将其中三个可独立复用的问题拆出处理：

• fix(axvirtio-blk): honor negotiated request limits #2510 修正块请求限制
• feat(axvm): expose Q35 ECAM for x86 UEFI guests #2501 补齐 Q35 ECAM
• fix(axvm): preserve legacy PIC interrupt delivery #2518 的 legacy PIC 中断投递修复

PR #2275

这个分支验证了 Axvisor 的 x86_64 guest 不再通过 fw_cfg 获取外部 kernel/initramfs，而是让 OVMF 从 VirtIO PCI 磁盘读取 ESP，经 GRUB 启动 Linux，最后由内层 initramfs 输出 AXVISOR_X86_UEFI_DISK_PASSED。

阻塞问题

目前 UEFI 启动 x86 客户机的链路已经完成验，但启动盘资产的生成、获取和更新方式尚未确定。#2275 仍用上传手工构建的压缩包、运行前解压的临时方案，启动盘没有明确可复现的获取方式，目前想到的是两种：

• 在 tgosimages 上发布启动盘，能够比较方便地获取和复用已发布的盘，但是感觉灵活性欠缺：更换kernel、initramfs或启动参数都需要额外发布新的启动盘，会增加资产数量。
• 在 cargo xtask 命令里边加入准备启动盘的流程：将当前手工生成启动盘的过程参数化，根据配置获取 kernel、initramfs、GRUB 等资产并完成装盘，供 CI 和本地部署复用。

这个方案打算新增类似如下的配置：

[kernel]
source = "registry"
asset = "linux-x86_64"
version = "<固定版本>"
sha256 = "<摘要>"

[initramfs]
source = "local"
path = "./tmp/initramfs.cpio.gz"

[bootloader]
source = "registry"
asset = "grub-x86_64-efi"
version = "<固定版本>"
sha256 = "<摘要>"

[boot]
cmdline = "console=ttyS0 rdinit=/init"

使用时类似：cargo xtask axvisor guest prepare --manifest ./guest-assets.toml --output ./target/guest