周报（2026-02-22 至 2026-02-28）
开发分支
- axvisor: https://github.com/Iscreamx/axvisor/tree/feature/ebpf
- axebpf: https://github.com/Iscreamx/axebpf
总结
本周核心进展：将 guest-kprobe 的 BrkInject 路径从"能进入流程但不稳定"推进到"可重复验证"——命令解析补齐、keepalive 基线建立、detach 竞态处理完成，形成了可执行的 attach → fire → detach 全流程。
一、已完成工作
1. 命令入口补齐：--inject / --ret
此前 trace kprobe vm<id>:<addr> ... --inject 被 shell 直接拒绝，原因是命令树只有 usage 文本而未注册对应 flag。本周补齐该缺口，命令可正常进入 manager 路径并走后续注册/回滚逻辑（commit: 4f3f5d1，文件：kernel/src/shell/commands/trace.rs）。
2. VMM 侧地址翻译 hook 注册
新增 register_guest_kprobe_hooks() 统一注册 VMM 侧的 4 组地址翻译回调（commit: 4f3f5d1，文件：kernel/src/vmm/mod.rs）：
register_guest_pt_read_hook：读取 guest 页表项register_vm_ttbr1_hook：获取 VM 的 TTBR1_EL1register_gpa_to_hpa_hook：GPA→HPA 转换register_stage2_exec_hook：Stage-2 执行权限切换
3. BrkInject 端到端机制实现（axebpf）
在 axebpf 侧完成 BrkInject 核心实现（commit: 452e641），涉及 11 个文件、+959/-34 行：
- 地址翻译（
src/probe/kprobe/addr_translate.rs）：GVA→GPA→HPA 三级地址翻译，通过 hook 回调解耦 VMM 依赖 - BRK 注入与恢复（
src/probe/kprobe/manager.rs）：原指令备份、BRK #4 写入、detach 时原指令还原 - stale-BRK 恢复策略（
src/probe/kprobe/handler.rs）：处理 detach 竞态下残留 BRK 的安全恢复 - 新增测试（4 个测试文件）：覆盖地址翻译、handler、manager、context 四个维度
4. 建立 keepalive 验证基线
新增 scripts/ostool/prepare_arceos_mini_shell_guest.sh 准备 guest 镜像，支持 mini-shell 和 keepalive 模式。keepalive 模式解决了"guest 很快退出导致验证窗口消失"的问题，主机侧 shell 能在 VM 运行期间保持可交互。
5. BrkInject 端到端验证通过
在 qemu-aarch64-shell + keepalive guest 场景下验证：
trace kprobe vm1:0xffff800000002878 printk --inject
验证结果：
- attach 成功，
trace list中 HITS 持续增长 trace stream --filter kprobe -n 5可观测到事件- detach 后探针可清理且 VM 保持 Running
- 连续多轮快速
attach/detach压测未再复现EC_60/Brk64 panic
6. 文档与集成说明更新（axebpf）
更新 README（commit: 2383fa5），补充 guest-kprobe 集成指南与验证步骤。
二、遇到的问题与解决方案
2.1 detach 后 stale BRK 竞态
问题：快速 attach/detach 场景下，detach 已完成但 guest vCPU 仍在执行 BRK 指令，触发 EC_60/Brk64 panic。
原因：BRK 写入到 guest 内存后，vCPU 可能已 fetch 该指令但尚未执行；detach 恢复原指令后 vCPU 仍会命中 BRK。
解决方案：在 handler 中增加 stale-BRK 检测——若当前 PC 处已无注册探针，识别为 stale BRK，恢复原指令并跳过 eBPF 回调，不触发 panic。
2.2 guest 退出窗口过短导致验证失败
问题：默认 guest 启动后快速退出，attach 命令来不及执行。 解决方案：引入 keepalive 模式的 guest 镜像，延长交互窗口，确保 attach/verify/detach 有充足时间。
2.3 cpu_ids vs phys_cpu_ids 语义差异
问题：phys_cpu_ids = [1] 在当前配置路径中不生效，导致预期的 CPU 亲和性未应用。
现状：以 cpu_ids = [1] 为准（当前配置解析实现决定），已在验证中统一使用。
三、关键验证记录
| 日期 | 验证动作 | 结果 |
|---|---|---|
| 02-22 | trace kprobe ... --inject 解析链路 |
已可解析并进入注册路径；guest 退出窗口下会回滚，且无脏项残留 |
| 02-24 | 引入 keepalive 镜像并复验 attach | 解决交互窗口问题；仍出现过 VM TTBR1_EL1 is not ready 的时序失败并自动回滚 |
| 02-25 | stale-BRK 修复后复验 + 压测 | attach → fire → detach 可复现通过；3 轮快速压测无 Brk64 panic |
补充说明：
- 高频热点下
hprobe_entry仍可能产生 OOB 日志噪声，本周验证主用printk规避干扰。
四、工作量统计
| 仓库 | 提交数 | 变更文件数 | 新增 | 删除 |
|---|---|---|---|---|
| axebpf | 2 | 12 | +1125 | -210 |
| axvisor | 2 | 4 | +108 | -5 |
本期关键新增 / 变更文件：
src/probe/kprobe/addr_translate.rs（地址翻译机制扩展）src/probe/kprobe/manager.rs（BrkInject 核心逻辑）src/probe/kprobe/handler.rs（stale-BRK 恢复）tests/guest_addr_translate_tests.rs、tests/guest_kprobe_handler_tests.rs、tests/guest_kprobe_manager_tests.rs（新增测试）kernel/src/vmm/mod.rs（VMM hook 注册）
五、当前判断
- BrkInject 路径已达到"本阶段可验收"的稳定度，建议继续作为 guest-kprobe 的主验证通道。
- Stage-2 fault 路径仍未完善，当前策略保持"明确标注限制 + 不作为本周验收前置条件"。
六、遗留问题
| 问题 | 现状 | 影响 | 解决方向 |
|---|---|---|---|
| Stage-2 fault 命中后恢复不完整 | 缺少 MDSCR_EL1.SS + EC::SingleStepLowerEL 完整机制 |
命中点可能重复 fault，形成忙循环 | 实现 single-step 基础设施，命中后单步执行原指令再重新挂 XN |
interrupt_mode = "emu"/"no_irq" 路径未实现 |
仍可能触发 not yet implemented panic |
无法覆盖所有中断模式场景 | 按需补齐分支或显式拒绝不支持的模式 |
| 全仓 clippy 基线问题 | cargo xtask clippy 受历史 lint 阻塞 |
本功能线无法独立完成质量门禁 | 分批清理历史 lint，或在 CI 中按模块单独检查 |
七、提交摘要
| 仓库 | 提交 | 说明 |
|---|---|---|
| axvisor | 4f3f5d1 |
guest-kprobe VMM hook 注册 + --inject 命令链路接入 |
| axvisor | 55db87c |
同步 axebpf 子模块到 guest-kprobe 实现版本 |
| axebpf | 452e641 |
地址翻译 hook、BrkInject 核心实现、stale-BRK 恢复 + 测试 |
| axebpf | 2383fa5 |
文档：guest-kprobe 集成验证指南更新 |
八、下周计划
| 优先级 | 任务 | 验收标准 |
|---|---|---|
| P0 | Stage-2 单步恢复基础设施 | 命中后可执行原指令并重新挂回 XN，不再循环 fault |
| P0 | 稳定化 BrkInject 验证脚本 | 固化一键复验流程（build/attach/stream/detach）并可重复通过 |
| P1 | 降低高频热点下 OOB 噪声 | hprobe_entry 在热点函数下可稳定运行 |
| P1 | 清理 clippy 历史阻塞项 | cargo xtask clippy 在主线配置可通过 |
九、个人复盘
这周最大的变化不是"新增了多少功能"，而是验证方法本身被固化了。
之前的问题是多因素叠加：命令解析、guest 生命周期窗口、detach 竞态——任一环节出问题都会让结论失真。现在通过 keepalive 基线和 stale-BRK 恢复策略，BrkInject 已经具备重复回放能力，后续可以把精力集中在 Stage-2 单步机制完善，而不是反复排查环境偶发因素。
另一个收获是：地址翻译的 hook 解耦设计证明了可行性——axebpf 不直接依赖 VMM 实现，而是通过回调注册让 VMM 在启动时注入翻译能力，这使得 guest-kprobe 模块可以独立测试（4 个新增测试文件均不依赖完整 VMM 环境）。