周报(2.8 - 2.21)
开发分支
- axvisor: https://github.com/Iscreamx/axvisor/tree/feature/ebpf
- axebpf: https://github.com/Iscreamx/axebpf
一、已完成工作
Probe 模块重构(axebpf):将探针代码重组为
probe/hprobe与probe/kprobe两层结构,并补齐对应 manager/handler 接口(commit:9154c68)。效果:VMM hprobe 与 guest kprobe 的代码边界更清晰,后续功能扩展成本更低。TraceContext 扩展(axebpf):新增
probe_type字段用于区分事件来源(commit:68118bc)。效果:同一统计/输出通路可以识别 tracepoint、hprobe、kprobe 等不同类型。ELF 加载器切换到 aya-obj(axebpf):runtime 从手写解析切换到 aya-obj,覆盖 map 重定位和函数调用重定位流程(commit:
ab494b8,当前见modules/axebpf/src/runtime.rs)。效果:ELF 兼容性提升,解析流程与主流 eBPF 工具链对齐。统一事件管线(axebpf):新增
event.rs,定义 64BTraceEvent,实现 RingBuf + fallback queue + 内置统计聚合(commit:9a76fd8,文件:modules/axebpf/src/event.rs)。效果:trace stream/dump/stat可直接消费统一事件流。RingBuf Map 内核侧支撑(axebpf):新增
MapType::RingBuf、vmap/unmap、页分配与 PollWaker(modules/axebpf/src/maps.rs、modules/axebpf/src/map_ops.rs、modules/axebpf/src/vmap.rs)。效果:支持事件流式输出所需的 RingBuf 数据面。Helper 能力补充(axebpf):新增
bpf_probe_read_kernel对应 helper ID113,并将 lookup 缓冲区从 256B 扩展到 512B(modules/axebpf/src/helpers.rs)。tracepoint→事件流接入(axebpf):
tracepoints/stats.rs、tracepoints/vmm.rs、tracepoints/shell.rs改为通过统一事件/统计管线记录数据(commit:9a76fd8)。效果:tracepoint 与 probe 统计口径统一。Shell 命令面增强(axvisor):
- 新增
trace stream/trace dump,支持--filter、-n(commit:662b3e6,文件:kernel/src/shell/commands/trace.rs) trace stat增加--hist、--top(同上)- 将 VMM 侧命令由
kprobe更名为hprobe,并增加 guest-kprobe 命令路径(commit:2898252)
- 新增
构建与符号注入流程改造(axvisor):
- 从
include_bytes!方式切换到 linker section + build 后注入(commit:96abd6a) - 将 kallsyms 注入改为 ELF 原地写入,修复 cargo hardlink 场景下符号丢失(commit:
916b8e7,文件:xtask/src/symbols.rs) qemu-aarch64配置默认启用guest-kprobe(commit:708a828)
- 从
工程清理(axvisor):移除独立
ebpf-programs与xtask build-ebpf流程(commit:eb61c44),并同步子模块指针到支持 hprobe/guest-kprobe 的版本(commit:cfc9e8b)。
二、待完善
| 问题 | 代码现状 | 解决方向 |
|---|---|---|
| guest kprobe 处理未真正“接管”异常 | handle_stage2_exec_fault / handle_guest_brk 当前匹配后仍返回 false(modules/axebpf/src/probe/kprobe/handler.rs) |
完成异常路径接管与恢复语义,返回已处理状态 |
| guest 寄存器上下文尚未接入 eBPF | 运行时调用为 run_program(prog_id, None)(同文件) |
接入真实 guest TrapFrame/pt_regs 上下文 |
| guest kprobe 注入机制未落地 | manager 中 Stage-2 XN / BRK 写回仍是 TODO(modules/axebpf/src/probe/kprobe/manager.rs) |
实现 GVA→GPA/HVA 转换、写保护切换、原指令恢复 |
| PerCpu/PerfEventArray 仍未支持 | map_ops.rs 中相关能力返回 NotSupported |
按实际需求补齐 map 类型支持 |
| 统计 reset 未实现 | shell 中 trace reset 仍提示不支持(kernel/src/shell/commands/trace.rs) |
增加统计状态重置 API |
三、遇到的问题与解决方案
3.1 kallsyms 注入后在后续流程中失效
问题:构建后注入符号在后续步骤中可能失效,导致运行时符号表异常。
原因:rust-objcopy --update-section 会产生新 inode,与 cargo hardlink 机制冲突。
解决方案:改为解析 ELF 后定位 .kallsyms section 并原地写入(xtask/src/symbols.rs::inject_kallsyms),并在需要生成 .bin 时重新导出。
3.2 RingBuf 需要页分配与连续虚拟映射支持
问题:事件流输出需要 RingBuf,但早期 map 层不支持 page alloc/vmap。
解决方案:在 AxKernelAuxOps 中实现 alloc_page/free_page/vmap/unmap,新增 vmap.rs 处理页表映射,并配套 PollWaker。
3.3 统计与输出路径分散
问题:tracepoint 与 probe 的统计/展示口径不一致。
解决方案:引入统一 TraceEvent 管线,所有来源统一 emit_event(),shell 使用 trace stream/dump/stat 直接消费聚合结果。
四、工作量统计
统计区间:2026-02-08 ~ 2026-02-21(基于本地
git log)
| 仓库 | 提交数 | 变更文件数 | 新增 | 删除 |
|---|---|---|---|---|
| axebpf | 8 | 38 | 2117 | 1394 |
| axvisor | 9 | 36 | 932 | 1212 |
本期关键新增文件:
modules/axebpf/src/event.rsmodules/axebpf/src/vmap.rs
本期关键命令能力(shell):
trace stream [--filter TYPE] [-n N]trace dump [--filter TYPE] [-n N]trace stat [--hist EVENT] [--top N]trace hprobe / hretprobe / unhprobetrace kprobe / unkprobe(guest)
五、下阶段计划
| 优先级 | 任务 | 说明 |
|---|---|---|
| P0 | 完成 guest kprobe 异常接管闭环 | handler 命中后返回已处理,并实现恢复路径 |
| P0 | 接入真实 guest 上下文给 eBPF 程序 | 替换 run_program(..., None) |
| P1 | 完成 Stage-2 / BRK 注入机制 | 落地 manager 中 TODO(地址转换、权限切换、原指令恢复) |
| P1 | 完善统计重置能力 | 提供 trace reset 可用实现 |
| P2 | 扩展 map 能力 | 按需补齐 PerCpu/PerfEventArray |
六、风险与阻塞项
| 风险项 | 影响 | 缓解措施 |
|---|---|---|
| guest kprobe 仍处于“注册/命中统计优先”阶段 | 端到端探针行为不完整 | 先补齐异常接管与恢复语义,再扩大使用范围 |
| RingBuf/vmap 涉及页表操作 | 错误处理不足时可能影响稳定性 | 增加异常路径回滚与压力测试 |
| 统计功能快速迭代中 | 指标口径可能出现阶段性变化 | 在文档中固定字段定义并同步 shell 展示 |
七、个人日志
7.1 本期最关键的架构变化
从“tracepoint/hprobe/kprobe 各自上报”转为“统一 TraceEvent 上报 + 统一统计聚合”。这使得 shell 侧 stream/dump/stat 不再依赖每条路径的特化代码。
7.2 对工程流程的改进
kallsyms 原地注入和 QEMU 运行前强制刷新符号,显著降低了“构建成功但符号不可用”的隐性问题。
7.3 当前技术判断
guest-kprobe 的命令面和 registry 已基本成形,但异常路径接管、上下文传递与注入恢复机制仍是决定可用性的核心缺口,下一阶段应优先闭环这一条主链路。