周报（2026-03-16 至 2026-03-22）

开发分支

• axvisor: https://github.com/Iscreamx/axvisor/tree/feature/ebpf
• axebpf: https://github.com/Iscreamx/axebpf/tree/main
• axvm: https://github.com/Iscreamx/axvm/tree/feature/ebpf
• arm_vcpu: https://github.com/Iscreamx/arm_vcpu/tree/feature/ebpf

总结

这周最重要的一件事，是把 Linux guest uprobe 从“内部代码路径已经通了”做到“在 QEMU AArch64 + Linux guest 里真的能打到用户态函数”。现在这条链路已经能看到 pending -> active -> real-hit。除此之外，还顺手修了几个一直影响验证体验的问题，包括 guest-kprobe 的 single-step 执行窗口、deferred probe 的自动启用、trace stream -n 的等待逻辑，以及 shell 线程占着 boot CPU 的干扰。

一、已完成工作

1. Linux guest uprobe 链路

• axebpf 核心实现（e491af7）：新增 probe/uprobe/* 运行时，覆盖 guest 用户态地址翻译、对象符号加载、hidden runtime observer、pending/active 管理，以及 EL0 BRK 命中后的 single-step 恢复；同时补上了一批 guest-uprobe 测试。
• axvisor 主线接入（bfcd54f）：接入 guest-uprobe feature，增加 trace uprobe / trace unuprobe / trace uloadelf / trace list 命令，并把 uprobe 依赖的 VMM hook 和 VM-exit 时机接进主仓。
• 运行时状态准备（136bba1、9c95f10）：在 axvm / arm_vcpu 中把 TTBR0_EL1、CONTEXTIDR_EL1、TPIDR_EL0 等 guest exit state 暴露出来并缓存，hidden observer 才能拿到 Linux guest runtime token。
• 底层依赖补充（a859bb8、6d07494）：一边让 executable guest mappings 可用，一边把 tracing symbol sections 导出出来，userspace patching 这条链路才算有了落脚点。

2. guest-kprobe 链路

• single-step 执行窗口修复（e638119）：single-step 前先打开 execute window，避免命中后恢复原指令时还被执行权限拦住；guest_kprobe_handler_tests 也补上了这条测试。
• VM-exit 后自动启用 deferred probe（065714d）：在 notify_guest_vmexit() 里自动尝试启用已经注册、但之前条件还不满足的 guest-kprobe，attach 时序不再那么挑人。
• 子模块版本统一收口（c0d78ea）：把本周 axebpf / axvm / arm_vcpu / axaddrspace / 平台层依赖的提交统一同步到 axvisor 主线，避免主仓和子模块状态继续错位。

3. 观测和交互

• guest-kprobe 日志降噪并补命中进度（f893848）：热点路径不再刷一堆没用日志，命中了多少次也能更直接地从日志里看出来。
• trace stream -n 改成真正按数量等待（0a6f21f）：修掉指定事件数后还去轮询键盘输入的问题，非交互脚本现在能老老实实等到目标条数。
• shell 线程移到非 boot CPU（bd44cf0）：把 shell 线程从 boot CPU 挪开，host shell 对 guest tracing 路径的打扰少了一截。

4. 运行配置

• guest cmdline 透传修复（dc1c8c4）：VM 配置转换时不再把 guest cmdline 丢掉，Linux guest 的验证配置和用户态程序自启动终于能按预期带进去。

二、遇到的问题与解决方案

2.1 Linux guest uprobe 只有 pending，没有真实激活事件

问题：MVP 阶段最多只能把 uprobe 挂成 pending。真正缺的不是 patching 代码，而是 Linux guest 里的 exec/mmap 事件源；没有这层 runtime 观察，probe 永远进不了 active。 解决方案：e491af7 里补了 linux_runtime_observer，再配合 bfcd54f、136bba1、9c95f10 提供的 runtime state，在 VM-exit 后注册 hidden observer，把 Linux guest runtime 事件真正接进 pending -> active 这条激活链。

2.2 guest-kprobe 命中后 single-step 仍可能卡在执行权限窗口

问题：如果 single-step 前不先打开 execute window，恢复原指令时还是会撞上执行权限限制，结果就是命中链路时好时坏。 解决方案：e638119 把 handler 时序调整了一下，在 single-step 前先把执行窗口打开，并加测试把这条修复钉住。

2.3 自动化验证容易受交互行为干扰

问题：自动化验证里有两个很烦人的干扰项。一个是 trace stream -n 指定条数后还会去看键盘输入，另一个是 shell 一直压在 boot CPU 上，guest tracing 的观测结果容易被搅乱。 解决方案：0a6f21f 让 stream -n 只盯着目标事件数，bd44cf0 把 shell 线程移到非 boot CPU，脚本化验证终于清净一些了。

三、下周计划