Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

周报（2026-03-30 至 2026-04-12）

开发分支

总结

这两周没有再往共享库 uprobe/uretprobe、dlopen 生命周期这些方向扩功能，主要还是把已经做出来的主线能力尽量联调透、验证透、文档也补齐。现在 tracepoint、hprobe/hretprobe、guest-kprobe/kretprobe、guest-uprobe/uretprobe 已经能放进同一条真实的 QEMU + AxVisor + Linux guest 链路里跑，现场手工演示、fresh 验证和日志验收也都整理出来了。

这两周做下来，边界其实也更清楚了。主程序场景下的 guest-uprobe/guest-uretprobe 已经基本可以算做成了；但共享库、多对象映射、dlopen/dlclose 动态装载生命周期这条线没有闭环，所以这次没有继续硬往前推，而是把为什么没做完、后面如果有人接着看应该从哪里下手，单独写成了说明文档。

一、这两周完成的主要工作

1. 把七类能力收成一条主线联调链路

这两周最主要的事情，是把原来分开验证的 tracing 能力收成一条主线联调链路。现在在同一次真实运行里，已经可以覆盖：

类型 目标点 当前状态
uprobe /usr/bin/axebpf_integration_demo:demo_user_entry pass
uretprobe /usr/bin/axebpf_integration_demo:demo_user_compute pass
guest-kprobe vm1:gic_handle_irq pass
guest-kretprobe vm1:__arm64_sys_getpid pass
hprobe notify_guest_vmexit pass
hretprobe notify_guest_vmexit pass
tracepoint vmm:timer_tick pass

这里真正有价值的，不只是“这些点能 attach 上”，而是 attach、guest 启动、运行期命中、收尾 trace list、收尾 trace stat 这几段已经能前后接起来，不再是靠零散实验凑证据。

2. 统一了 guest demo、rootfs 和触发路径

  • 使用单 guest demo：scripts/ostool/assets/linux_axebpf_integration_demo/axebpf_integration_demo.c
  • demo 在一次运行里主动触发用户态函数、getpid、文件 I/O 和重复窗口，作为七类能力联调的统一触发源
  • 固化 rootfs 准备脚本：scripts/ostool/prepare_linux_axebpf_integration_demo_rootfs.sh
  • 继续通过 inittab + launcher 直接拉起 demo，避免 guest shell 和 host AxVisor shell 争用串口

这套东西整理完之后，现场演示和 fresh 回归都不用再临时拼步骤了。

3. 补齐自动化验收和人工联调文档

  • 新增总控脚本：tmp/run_axebpf_mainline_integration_real.py
  • 新增日志验收脚本：scripts/verify/check_axebpf_mainline_integration_log.py
  • 固化主线 workflow：docs/ebpf-tracing/axebpf-mainline-integration-workflow.md
  • 固化现场手工演示手册：docs/ebpf-tracing/axebpf-mainline-integration-manual-workflow.md
  • 固化能力矩阵：docs/ebpf-tracing/axebpf-mainline-integration-matrix.md

现在脚本已经能自动完成构建、镜像准备、attach、guest 启动、日志抓取、trace list/stat 收尾和最终 PASS/FAIL 校验；手工手册则对应现场演示，按文档一步步走，也能看到同样的结果。

二、最新联调结果

这轮 fresh 验证已经通过，验收摘要如下：

  • hprobe_entry=2781
  • hretprobe=2781
  • guest-kprobe gic_handle_irq=1129
  • guest-kretprobe __arm64_sys_getpid=14
  • vmm:timer_tick 的 attachment 和 map activity 都存在

联调过程中，几类关键证据现在都能稳定看到：

  1. guest 启动后可以看到 axebpf_integration_demo wrapper: launch 和 demo:start
  2. 运行期可以看到 guest_uprobe_hit 和 guest_uretprobe_hit
  3. 同一运行窗口里可以看到 guest_kprobe_hits: kprobe vm1:gic_handle_irq ...
  4. 同时也可以看到 guest_kprobe_hits: kretprobe vm1:__arm64_sys_getpid ...
  5. host 侧能持续看到 [hprobe] ENTRY/EXIT ... notify_guest_vmexit
  6. demo 结束后，收尾 trace list 和 trace stat 都能拿到非零命中结果

这里有两个点需要单独说明。

2.1 guest-uprobe/guest-uretprobe 的收尾表现

guest 进程退出后，收尾 trace list 里不会保留 active 实例，而只会剩下 pending 模板，并显示 waiting-for-instance。这不是失败，而是当前实现下实例会随着进程退出一起回收。

所以这类能力到底有没有跑通，主要还是看运行期 raw log 里的：

  • guest_uprobe_hit
  • guest_uretprobe_arm
  • guest_uretprobe_hit

2.2 hprobe 日志比较密

hprobe/hretprobe 的命中频率很高。如果 demo 结束后不及时关闭 verbose，串口很容易被刷屏，最后抓快照反而不好看。所以现在 workflow 和手工手册里都统一要求在 demo:done 之后立即执行：

  • trace verbose off

再抓最终的 trace list 和 trace stat。

三、为什么共享库等功能当前不可用

这两周没有继续把共享库 uprobe/uretprobe、dlopen 场景往下推进，不是因为“只差最后一点”，而是因为它已经超出了当前这个收尾阶段适合继续扩展的范围。

3.1 现在做成的是“主程序场景”，还不是“完整对象模型”

现在主线里已经能用的是：

  • 主程序路径下的 guest-uprobe
  • 主程序路径下的 guest-uretprobe
  • 基于当前运行实例的进程隔离和回收

但共享库场景要处理的，不只是主程序映射基址，而是一个真正的“多对象运行时模型”，至少包括：

  • 每个共享库各自独立的 load bias
  • 重定位后的运行时地址
  • dlopen/dlclose 带来的对象创建、激活、回收生命周期
  • 同一进程内多个 file-backed executable mapping 的对象识别

这些状态，目前都还没有在主线里统一建模完成。

3.2 真实失败点在 runtime observer 的对象识别阶段

这轮共享库验证里，guest 内部其实已经能把下面几步跑起来：

  • 动态程序启动
  • dlopen 成功
  • 目标共享库函数被调用

但 host 侧没有把这次共享库映射识别成一个能和 pending binding 对上的目标对象，所以 probe 一直停在 pending。也就是说，真实问题不在“公式是不是算对了”，而是在 observer 的对象路径和实例识别这一步就没接上。

这轮实际看到的典型现象是：

  • dlopen 后 observer 能看到 executable file-backed mmap
  • 但日志里会出现 reason=no_pending_path
  • 最终 trace list 中始终只有 pending 模板，没有共享库实例进入 active

3.3 这时候更适合收口，不适合继续开新功能

这次没有继续修共享库能力，主要有三个原因：

  1. 这已经不是补一个小接口就能结束的问题，而是要继续改 runtime observer 的对象路径来源和实例识别逻辑
  2. 主程序场景和主线联调能力已经可以形成一份完整交付，再继续扩共享库，会把收尾重新拖回新功能开发
  3. 现阶段更合理的目标，是把已经做成的能力联调清楚、验证清楚、文档写清楚，便于后续交接

所以这两周的取舍是明确的：先不扩共享库，而是把已经做成的能力收成一条可复现、可演示、可验收的完整链路。

共享库未完成原因已经单独整理到：

  • docs/ebpf-tracing/shared-library-uprobe-status.md

四、下一步收口方向

后续工作不再增加新功能，而是继续围绕现有主线能力做交接式收口：

  1. 继续以 tmp/run_axebpf_mainline_integration_real.py 作为 fresh 回归主入口
  2. 如需现场演示，优先按 docs/ebpf-tracing/axebpf-mainline-integration-manual-workflow.md 执行
  3. 如需回看主线联调逻辑，优先看 workflow、matrix 和最新 PASS raw log
  4. 如果后续有人继续做共享库支持，直接从 docs/ebpf-tracing/shared-library-uprobe-status.md 和对应 raw log 入手

接下来工作的重点，不再是继续往外扩，而是把已经做完的这部分能力保持在可联调、可复现、可交接的状态。就这两周的目标来说，这部分已经基本达到预期。