2026开源社区实习项目-ebpf支持计划

[Iscreamx]

AxVisor eBPF 性能追踪系统

实习项目: 为 AxVisor Hypervisor 实现基于 eBPF 的动态性能追踪系统

参考实现: Starry-OS eBPF 支持

---

1. 项目背景

1.1 问题陈述

AxVisor 是基于 ArceOS 构建的模块化 Type-1 Hypervisor。当前的可观测性依赖于静态日志输出，存在以下局限：

局限性	影响
无延迟统计	无法分析 VM Exit、Hypercall 等关键路径的处理时长
无频率分析	无法统计事件发生频率和分布
静态插桩	修改追踪点需要重新编译
高开销	日志 I/O 影响性能

1.2 解决方案

引入 eBPF 技术，实现：

• 动态追踪: 运行时加载/卸载追踪程序，无需重编译
• 低开销: 内核空间聚合统计，避免频繁日志输出
• 可编程: 用户可编写自定义 eBPF 程序，灵活定义采集逻辑
• 安全: 验证器保证程序安全，不会导致 Hypervisor 崩溃

1.3 技术路线

由于 Starry-OS 是基于 ArceOS 扩展的宏内核，AxVisor 是基于 ArceOS 扩展的 VMM，两者共享底层基础设施。本项目将移植并扩展 Starry-OS 的 eBPF 实现，适配 Hypervisor 场景。

---

2. 系统架构

┌───────────────────────────────────────────────────────────────────────────────────────┐
│                          AxVisor eBPF Tracing Architecture                            │
├───────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                       │
│  ┌───────────────────────────────────────────────────────────────────────────────┐    │
│  │                            User Interface Layer                               │    │
│  │   ┌───────────────────────────────────────────────────────────────────────┐   │    │
│  │   │  Shell: trace list | enable | disable | stat | load                   │   │    │
│  │   └───────────────────────────────────────────────────────────────────────┘   │    │
│  └───────────────────────────────────────┬───────────────────────────────────────┘    │
│                                          │                                            │
│  ┌───────────────────────────────────────▼───────────────────────────────────────┐    │
│  │                            axebpf Module                                      │    │
│  │   ┌───────────────────────────────────────────────────────────────────────┐   │    │
│  │   │ symbols.rs    │ Symbol Table Management (ksym)                        │   │    │
│  │   ├───────────────────────────────────────────────────────────────────────┤   │    │
│  │   │ tracepoint.rs │ Static Tracepoint Framework                           │   │    │
│  │   ├───────────────────────────────────────────────────────────────────────┤   │    │
│  │   │ kprobe.rs     │ Dynamic Probes (kprobe/kretprobe)                     │   │    │
│  │   ├───────────────────────────────────────────────────────────────────────┤   │    │
│  │   │ runtime.rs    │ eBPF VM (rbpf)                                        │   │    │
│  │   ├───────────────────────────────────────────────────────────────────────┤   │    │
│  │   │ verifier.rs   │ Program Verifier                                      │   │    │
│  │   ├───────────────────────────────────────────────────────────────────────┤   │    │
│  │   │ helpers.rs    │ Helper Functions (Standard + Hypervisor Specific)     │   │    │
│  │   ├───────────────────────────────────────────────────────────────────────┤   │    │
│  │   │ maps.rs       │ Map Data Structures (HashMap, Array, RingBuf)         │   │    │
│  │   └───────────────────────────────────────────────────────────────────────┘   │    │
│  └───────────────────────────────────────┬───────────────────────────────────────┘    │
│                                          │                                            │
│  ┌───────────────────────────────────────▼───────────────────────────────────────┐    │
│  │                         VMM Instrumentation Points                            │    │
│  │   ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐              │    │
│  │   │vcpu_run_*  │  │ hypercall  │  │ mmio_*     │  │ ept_viol   │              │    │
│  │   └────────────┘  └────────────┘  └────────────┘  └────────────┘              │    │
│  └───────────────────────────────────────────────────────────────────────────────┘    │
│                                                                                       │
│  ┌───────────────────────────────────────────────────────────────────────────────┐    │
│  │                       Starry-OS Dependencies                                  │    │
│  │   ┌────────┐  ┌────────────┐  ┌──────────┐  ┌──────┐  ┌───────────┐           │    │
│  │   │  ksym  │  │ tracepoint │  │  kprobe  │  │ rbpf │  │kbpf-basic │           │    │
│  │   └────────┘  └────────────┘  └──────────┘  └──────┘  └───────────┘           │    │
│  └───────────────────────────────────────────────────────────────────────────────┘    │
│                                                                                       │
└───────────────────────────────────────────────────────────────────────────────────────┘

---

3. 核心功能

3.1 追踪点 (Tracepoint)

预定义的静态插桩点，适用于 Hypervisor 关键路径：

追踪点	触发位置	采集数据
vmm:vcpu_run_enter	VM Entry	vm_id, vcpu_id, timestamp
vmm:vcpu_run_exit	VM Exit	vm_id, vcpu_id, exit_reason, duration_ns
vmm:hypercall	Hypercall 处理	vm_id, nr, args, duration_ns
vmm:mmio_access	MMIO 模拟	vm_id, addr, width, is_write, duration_ns
vmm:ept_violation	嵌套页表错误	vm_id, gpa, access_flags, duration_ns
vmm:interrupt_inject	中断注入	vm_id, vcpu_id, vector

3.2 动态探针 (Kprobe/Kretprobe)

支持在任意内核函数入口/返回处动态插桩，无需预定义追踪点：

# 在 AxVCpu::run 函数入口插桩
trace kprobe axvcpu::AxVCpu::run

# 在函数返回处插桩，捕获返回值
trace kretprobe axvcpu::AxVCpu::run

3.3 Hypervisor 专用 Helper

除标准 eBPF Helper 外，提供 Hypervisor 上下文访问：

Helper ID	函数	功能
100	bpf_get_current_vm_id	获取当前 VM ID
101	bpf_get_current_vcpu_id	获取当前 vCPU ID
102	bpf_get_exit_reason	获取 VM Exit 原因
103	bpf_get_guest_regs	获取 Guest 寄存器状态

3.4 预期效果

axvisor:/$ trace list
Tracepoints:
  vmm:vcpu_run_enter     [disabled]
  vmm:vcpu_run_exit      [disabled]
  vmm:hypercall          [disabled]
  vmm:mmio_read          [disabled]
  vmm:mmio_write         [disabled]
  vmm:interrupt_inject   [disabled]
  vmm:ept_violation      [disabled]

Kprobes:
  (none)

axvisor:/$ trace enable vmm:vcpu_run_exit
Enabled: vmm:vcpu_run_exit

axvisor:/$ trace enable vmm:hypercall
Enabled: vmm:hypercall

axvisor:/$ trace stat
┌──────────────────────────────────────────────────────────────┐
│                    VM Exit Statistics                        │
├────────┬─────────┬──────────────┬─────────┬─────────┬────────┤
│ VM ID  │ vCPU ID │ Exit Reason  │  Count  │ Avg(μs) │ Max(μs)│
├────────┼─────────┼──────────────┼─────────┼─────────┼────────┤
│   1    │    0    │ Hypercall    │  12345  │   2.3   │  15.7  │
│   1    │    0    │ ExtInterrupt │   8901  │   1.1   │   8.2  │
│   1    │    0    │ Halt         │    567  │  45.2   │ 102.1  │
│   1    │    0    │ MmioRead     │   3456  │   1.8   │  12.3  │
│   2    │    0    │ Hypercall    │   4567  │   2.8   │  12.3  │
└────────┴─────────┴──────────────┴─────────┴─────────┴────────┘

axvisor:/$ trace latency hypercall
Hypercall Latency Distribution (VM 1, vCPU 0):
     μs : count    distribution
  0 - 1 : 5765   |████████████████████████████████        |
  1 - 2 : 3789   |█████████████████████                   |
  2 - 4 : 1923   |███████████                             |
  4 - 8 :  567   |███                                     |
  8 - 16:  234   |█                                       |
 16 - 32:   56   |                                        |
 32 - 64:   11   |                                        |

axvisor:/$ trace kprobe axvm::Vm::create
Kprobe attached: axvm::Vm::create @ 0xffff800080123456

axvisor:/$ trace list
Tracepoints:
  vmm:vcpu_run_enter     [disabled]
  vmm:vcpu_run_exit      [enabled]   1 program attached
  vmm:hypercall          [enabled]   1 program attached
  ...

Kprobes:
  axvm::Vm::create       [enabled]   @ 0xffff800080123456

---

4. 开发计划 (12 周)

4.1 时间线概览

Week 1-2        Week 3-4        Week 5-6        Week 7-8        Week 9-10       Week 11-12
   │               │               │               │               │               │
   ▼               ▼               ▼               ▼               ▼               ▼
┌───────────┐   ┌───────────┐   ┌───────────┐   ┌───────────┐   ┌───────────┐   ┌───────────┐
│  Phase 1  │──►│  Phase 2  │──►│  Phase 3  │──►│  Phase 4  │──►│  Phase 5  │──►│  Phase 6  │
│   Basic   │   │   eBPF    │   │    VMM    │   │  Kprobe   │   │ Verifier  │   │  Testing  │
│   Infra   │   │  Runtime  │   │Tracepoints│   │  Support  │   │  Uprobe   │   │   Docs    │
└───────────┘   └───────────┘   └───────────┘   └───────────┘   └───────────┘   └───────────┘

4.2 Phase 1: 基础设施 (Week 1-2)

目标: 集成 Starry-OS 组件，建立符号表和追踪点基础设施

任务	说明
依赖集成	引入 ksym, kbpf-basic, tp-lexer, tracepoint
模块创建	创建 modules/axebpf，包含子模块结构
符号表	实现 symbols.rs，集成 ksym；修改 xtask 生成 kallsyms.bin
追踪点框架	实现 tracepoint.rs，封装 tracepoint 库

交付物:

• modules/axebpf 模块
• xtask symbols 命令
• 追踪点定义宏可用

4.3 Phase 2: eBPF 运行时 (Week 3-4)

目标: 移植 rbpf VM，实现程序加载和执行

任务	说明
rbpf 集成	适配 rbpf 到 no_std 环境
VM 封装	实现 EbpfVm 结构体，支持 Helper 注册
Helper 实现	实现标准 Helper (map ops, ktime, trace_printk)
Map 支持	实现 maps.rs，封装 kbpf-basic (HashMap, Array, RingBuf)

交付物:

• eBPF 程序加载和执行
• 标准 Helper 函数 (6 个)
• Map 数据结构支持

4.4 Phase 3: VMM 追踪点与 Shell (Week 5-6)

目标: 定义 Hypervisor 追踪点，实现 Shell 命令

任务	说明
追踪点定义	定义 7+ 个 VMM 追踪点
VMM 插桩	在 axvcpu 关键路径插入追踪点
Shell 命令	实现 trace list/enable/disable/stat/load
Hypervisor Helper	实现 vm_id, vcpu_id, exit_reason Helper

交付物:

• VMM 追踪点可用
• Shell trace 命令组
• 端到端演示

4.5 Phase 4: Kprobe/Kretprobe 支持 (Week 7-8)

目标: 移植 Starry-OS kprobe 实现，支持动态探针

任务	说明
kprobe 移植	移植 Starry-OS kprobe 库
架构适配	适配 aarch64/x86_64 断点机制
kretprobe	实现函数返回探针
Shell 集成	trace kprobe/kretprobe 命令

交付物:

• Kprobe/Kretprobe 支持
• 动态探针 Shell 命令
• 多架构支持 (aarch64, x86_64)

4.6 Phase 5: 验证器与 Uprobe (Week 9-10)

目标: 实现 eBPF 验证器，探索 Uprobe 支持

任务	说明
验证器移植	集成 PREVAIL 或实现轻量验证器
安全检查	内存边界、程序终止性、类型安全
Uprobe 研究	研究 Guest 用户态追踪可行性
Uprobe 原型	实现基础 Uprobe 支持 (如可行)

交付物:

• eBPF 验证器
• 安全加载不受信程序
• Uprobe 可行性报告/原型

4.7 Phase 6: 测试与文档 (Week 11-12)

目标: 全面测试，编写文档，性能优化

任务	说明
单元测试	symbols, runtime, helpers, maps
集成测试	追踪点触发、eBPF 执行、kprobe
性能测试	追踪点开销、eBPF 执行延迟
文档	用户指南、API 文档、设计文档

性能目标:

• 追踪点禁用时：开销 < 1%
• 追踪点启用时：开销 < 5%
• eBPF 程序执行：< 1μs

交付物:

• 完整测试套件
• 性能基准测试报告
• 用户文档和开发文档

---

5. 依赖组件

5.1 Starry-OS 组件 (直接复用)

组件	功能	链接
ksym	符号表生成与查找	https://github.com/Starry-OS/ksym
tracepoint	追踪点框架	https://github.com/Starry-OS/tracepoint
kprobe	动态探针	https://github.com/Starry-OS/kprobe
kbpf-basic	eBPF Map/Helper	https://github.com/Starry-OS/kbpf-basic
tp-lexer	过滤表达式	https://github.com/Starry-OS/tp-lexer

5.2 社区组件

组件	功能	链接
rbpf	eBPF 虚拟机 (Rust)	https://github.com/qmonnet/rbpf
PREVAIL	eBPF 验证器	https://github.com/vbpf/ebpf-verifier

---

6. 未来扩展

6.1 完善 Uprobe 支持

Phase 5 将进行 Uprobe 可行性研究。在 Hypervisor 场景下，Uprobe 面临的挑战：

• Guest 用户态地址空间隔离
• 跨 VM 的断点管理
• 性能影响评估

如可行，将支持追踪 Guest OS 中的用户态程序。

6.2 Rust 异步追踪 (研究方向)

问题: 现有 eBPF 追踪方案基于同步执行模型，无法有效追踪 Rust async/await 异步代码：

• 执行碎片化: async 函数在 await 点被拆分为多个状态机片段，传统 kprobe 只能捕获单个片段
• 上下文丢失: Future 在不同执行器线程间迁移，无法通过线程 ID 关联完整调用链
• 状态机隐藏: 编译器生成的状态机代码与源码结构差异大，符号解析困难

研究方向: 探索针对 Rust async runtime 的专用追踪方案，可能需要：

• 与 async runtime (如 Embassy, async-std) 集成的追踪点
• Future 生命周期追踪
• 跨 await 的上下文传播机制

此方向需要进一步研究，不在当前 12 周计划范围内。

---

7. 参考资料

• Starry-OS eBPF Discussion
• eBPF 官方文档
• Aya - Rust eBPF 框架
• eBPF 指令集规范
• eBPF for Windows

[Iscreamx]

1.20 - 1.31

开发分支:
axvisor(https://github.com/Iscreamx/axvisor/tree/feature/ebpf)
axebpf(https://github.com/Iscreamx/axebpf)

已完成

• axebpf 独立模块 : 集成ksym, tracepoint, tp-lexer, kbpf-basic, rbpf 实现 eBPF 运行时, 支持程序加载执行, Array/HashMap/LruHash/Queue 四种 Map 类型, 6 个标准 helper 函数和 3 个 Hypervisor 专用 helper (获取 vm_id/vcpu_id/exit_reason). 效果: 可在 Hypervisor 内核中动态加载 eBPF 字节码进行追踪, 无需重新编译内核.
• Shell trace 命令 : 支持 trace list/enable/disable/stat/reset/load/unload/progs/latency/verbose 等命令. 效果: 可通过 shell 交互式启用追踪点, 附加 eBPF 程序, 查看统计数据和延迟直方图.
• Tracepoint 定义: 定义了 25+ 个 VMM 追踪点, 其中 VM 生命周期 (vm_create/boot/shutdown), 系统初始化 (vmm_init/config_load), Shell
  (shell_command/init) 等追踪点已完成插桩并正常工作. 效果: 可追踪 VM 创建启动流程和 shell 命令执行.
• 预编译 eBPF 程序: 基于 aya-ebpf 框架提供 2 个预编译程序, 支持 ELF 解析和 Map 重定位, 可通过 trace enable xxx --prog printk 附加程序, 无需手动编译:
  • printk: 事件计数器, 读取 tracepoint_id 并在 COUNTER_MAP 中累加调用次数
  • stats: 统计收集器, 收集 COUNT/TOTAL/MIN/MAX 延迟统计到 STATS_MAP
• 上游贡献: 向 Starry-OS/kbpf-basic 提交 PR 并已合并, 修复了 printf-compat 和 VaList API 在 Rust nightly >= 2025-12 上的兼容性问题. 使kbpf-basic 可在最新 nightly 工具链(2025-12-12)上正常编译.

待完善

• vCPU 运行时追踪点不可用 — vcpu_run_enter/exit, hypercall, external_interrupt 等核心追踪点已定义但未生效; 原因是 vCPU 实际运行循环位于 axvm crate 而非 kernel 侧, 需等待 axvm 模块重构后在其内部添加插桩.
• bpf_trace_printk 简化实现 — 当前直接打印参数值而非解析格式字符串; 原因是 rbpf VM 执行时无法访问 ELF .rodata 段中的格式字符串,
  需要实现内存映射机制.
• 验证器功能有限 — rbpf 内置基础验证器, 可检查内存越界和指令合法性; 但相比 Linux 内核验证器, 缺少循环终止性证明, 类型安全检查等高级功能. 当前依赖预编译可信程序规避风险.
• Kprobe/Kretprobe 未实现 — 下一步工作.

[Iscreamx]

2.1 - 2.7

已完成:

• Kprobe 基础设施: kprobe 库设计用于 EL1 宏内核环境, 而 AxVisor 作为 Type-1 Hypervisor 运行在 EL2, 异常处理入口和寄存器上下文完全不同, 无法直接复用. 本周实现了 EL2 环境下的 kprobe 断点捕获机制: 在 arm_vcpu 的 EL2 同步异常处理中识别 BRK 指令 (EC=0x3C), 将 Hypervisor 的 TrapFrame 转换为 eBPF 程序可访问的寄存器上下文, 执行完成后恢复正常执行流. 效果: 可在任意 Hypervisor 内核函数入口处动态执行 eBPF 程序.
• 符号表集成: 实现内核符号表加载机制, 使用页对齐结构嵌入 kallsyms 二进制数据满足 ksym 库要求, 获取内核代码段边界用于地址校验. 效果: kprobe 可通过符号名自动解析函数地址, 无需手动查找.
• Shell ksym 命令: 新增内核符号查找命令, 支持地址到符号名的双向解析, 以及模糊搜索功能. 便于定位 kprobe 挂载点.
• Shell trace kprobe 命令: 扩展 trace 命令组, 新增 kprobe/kretprobe/unkprobe 子命令, 支持按程序名自动加载预编译 eBPF 程序, trace list 扩展显示已注册 kprobe 的符号名, 地址, 命中次数, 程序 ID. 效果: 可通过 shell 交互式管理动态探针.
• axebpf 子模块化: 将 axebpf 改为 git submodule 引入. 效果: axebpf 可独立版本管理.
• axvm kprobe feature 传递: arm_vcpu 是 axvm 的依赖, 需要通过 feature flag 控制 kprobe 功能是否编译, 因此在 axvm 中添加 kprobe feature 并向下传递到 arm_vcpu.
• 链接器脚本更新: tracepoint 库使用特殊的 linker section 在链接时收集所有静态追踪点定义, 需要在 axplat-aarch64-dyn 的链接器脚本中添加 tracepoint 和 __static_keys 段的起止符号定义. 效果: 支持 tracepoint 静态插桩点的自动收集,.

待完善:

• 递归调用异常: 执行稍微复杂的 ebpf 程序时会出现 (Error: too many nested calls (max: 8)), 可能是递归 kprobe 触发, 待调试.
• Kretprobe 未完整验证: 函数返回探针需要栈帧管理机制, 当前仅完成命令接口框架.
• x86_64 架构支持待实现: 当前仅完成 aarch64 EL2 环境的适配, x86_64 需要适配 VMX root mode 的异常处理.

[Iscreamx]

2.8 - 2.21

已完成:

• Probe 模块重构：axebpf 按 probe/hprobe 与 probe/kprobe 拆分，管理与处理链路更清晰。
• Runtime 升级：ELF 加载从手写解析切换到 aya-obj，支持 map/call 重定位，程序加载稳定性提升。
• 统一事件通路：新增 TraceEvent（64B）与 event.rs，打通 tracepoint/hprobe/kprobe 的统一上报与统计。
• RingBuf 支撑落地：新增 RingBuf map 类型、vmap/unmap、页分配与PollWaker，支持 trace stream/dump。
• Helper 能力补充：新增 bpf_probe_read_kernel（helper id 113），lookup buffer 扩展到 512B。
• Shell 能力增强：新增 trace stream、trace dump、trace stat --hist/--top；VMM 侧命令统一为 hprobe，并接入 guest-kprobe 命令路径。
• 构建链路改进：kallsyms 改为 ELF 原地注入，修复硬链接场景符号丢失；QEMU 流程增加符号刷新。
• 配置与工程整理：qemu-aarch64 默认开启 guest-kprobe，移除独立 ebpf-programs 流程并同步子模块。

待完善:

• guest kprobe 处理链路未完全接管：命中后仍返回 false，异常处理闭环待完成。
• guest 寄存器上下文尚未接入 eBPF：当前仍为 run_program(..., None)。
• Stage-2/BRK 注入机制仍有 TODO：地址转换、权限切换、原指令恢复待实现。
• trace reset 暂未实现。
• PerCpu/PerfEventArray map 能力仍未支持。

[Iscreamx]

2.22 - 2.28

已完成:

• 命令入口补齐：trace kprobe vm: ... --inject / --ret flag 注册完成，命令可正常进入 manager 注册/回滚路径。
• VMM 侧地址翻译 hook 注册：新增 register_guest_kprobe_hooks() 统一注册 4
  组回调（guest 页表读取、TTBR1 获取、GPA→HPA 转换、Stage-2 执行权限切换），axebpf 通过 hook 解耦 VMM 依赖。
• BrkInject 端到端实现（axebpf）：完成 GVA→GPA→HPA 三级地址翻译、原指令备份与 BRK #4 写入、detach 时原指令还原，新增 4 个测试文件覆盖地址翻译/handler/manager/context。
• stale-BRK 竞态处理：handler 增加 stale-BRK 检测——detach 后若 vCPU 仍命中残留 BRK，安全恢复原指令而非 panic。连续多轮快速attach/detach 压测通过。
• keepalive 验证基线：新增 guest 镜像准备脚本，支持 keepalive 模式，解决 guest 快速退出导致验证窗口不足的问题。
• BrkInject 端到端验证通过：attach → fire → detach 全流程在 qemu-aarch64-shell + keepalive guest 下可重复验证（HITS 增长、stream 可观测、detach 后 VM 保持 Running）。

待完善:

• Stage-2 fault 命中后恢复不完整：缺少 MDSCR_EL1.SS + EC::SingleStepLowerEL 单步机制，命中点可能重复 fault 形成忙循环。
• interrupt_mode = "emu"/"no_irq" 路径未实现分支，仍可能触发 not yet implemented panic。

[Iscreamx]

3.1 - 3.8

已完成:

• guest symbol 工作流补齐：完成 guest 符号表支持，trace kprobe vm<id>:<symbol> 可按符号名挂载 guest-kprobe，trace list 也支持目标地址的符号化展示。效果：挂载点定位和复验成本显著下降，不再需要每次手工查地址。
• Stage-2 single-step 基础能力继续完善：补齐 guest TraceContext 的 x0-x7 透传，增加 VM lifecycle cleanup entrypoints，修复 multi-vCPU stepping race，并补强 manager / handler 测试稳定性。效果：guest-kprobe 命中后的恢复链路更完整，后续可以继续推进 Stage-2 fault 路径验证。
• VMM 侧 guest-kprobe hook 接入：在 axvisor 中统一注册 guest 页表读取、TTBR1 获取、GPA→HPA 转换、Stage-2 执行权限切换等回调，axebpf 通过 hook 解耦对 VMM 具体实现的依赖。效果：地址翻译与权限控制逻辑可以独立测试，也便于后续扩展不同路径的 guest-kprobe 实现。
• Stage-2 路径验证继续推进：在 qemu-aarch64-shell + keepalive guest 场景下持续推进 Stage-2 fault 路径验证，已经可以稳定观察到 single-step、XN restore、matched stage2 fault 等关键现象。效果：fault -> page-step -> 恢复 的主路径已基本打通，验证方式也比前几周更稳定。
• BrkInject 对照路径保持可复验：keepalive 基线持续可用，attach -> fire -> detach 全流程可以重复验证；stale-BRK 竞态处理保持稳定。效果：BrkInject 继续作为对照通道，用于隔离时序问题和 Stage-2 handler 问题。

待完善:

• TTBR1 时序：attach 时机过早时，guest 地址翻译稳定性仍会受影响。
• Stage-2 huge-page barrier ：same-page 非目标 fault 的处理路径还需要更多验证；多核场景下的 TLB shootdown 边界也还没有完全覆盖。
• Kretprobe ：返回探针相关的栈帧管理和完整闭环还需要继续补齐。trace reset、PerCpu/PerfEventArray map、更完整的验证器能力仍未实现。

[Iscreamx]

3.9 - 3.15

已完成:

• deferred attach 收口：上周的 deferred attach 机制正式提交。axvisor 侧 shell 的 trace kprobe 支持 pending attach 提示，当 TTBR1_EL1 尚未就绪时显式输出 "registered pending enable" 而非报错退出；VMM 侧将 VM-exit 通知收回到 kernel/src/vmm/mod.rs，去掉对 axvm 新接口的直接依赖，使 guest-kprobe 功能可在不修改 axvm crate 的前提下工作。
• guest kretprobe 返回探针实现（axebpf）：本周最主要的新功能，变更量 +1126/-145 行，涉及 10 个文件。核心包括三部分：1) per-vCPU return stack（return_stack.rs，新增文件），每个 vCPU 维护 LIFO 栈（最大深度 16），支持 push/pop_matching/retain 以及 VM 销毁和 probe detach 时的资源回收；2) 动态 return BRK 引用计数（manager.rs），通过 acquire_return_brk / release_return_brk 管理 return 地址处的动态 BRK 注入，解决多个 entry probe 共享同一 return 地址时的生命周期问题；3) handler 侧 entry/return 分流（handler.rs），entry hit 直接执行 eBPF 程序，return hit 从 x30 读取返回地址并注入 BRK，寄存器接口从 [u64; 8] 扩展为 [u64; 31] 覆盖 AArch64 全部通用寄存器。
• trace stream 修复：修复 trace stream -n <count> 模式下的交互问题，指定事件数量上限时不再轮询键盘输入，避免非交互场景下误触退出。
• VMM 配置 cmdline 透传：将 guest 的 cmdline 配置项透传到 AxVMConfig，为后续 guest 启动参数定制提供基础。

待完善:

• 多核下 return stack 跨核一致性：当前 per-vCPU 栈按物理 CPU 索引，若 vCPU 发生迁移，return hit 可能在错误的栈上查找，需评估是否改为 per-vcpu 索引。
• StarryOS / Linux guest 全功能验证：下两周将在 StarryOS / Linux guest 上跑通 hprobe、guest-kprobe（BrkInject + Stage-2）、kretprobe 全流程。
• uprobe 设计：下两周第二周启动 uprobe 方案设计，覆盖 guest 用户态地址翻译（TTBR0_EL1）、ELF 符号解析、BRK 注入策略、与 kprobe 的复用/差异分析。

[Iscreamx]

3.16 - 3.22

已完成:

• Linux guest uprobe 主链路打通：这周最核心的工作，是把 Linux guest uprobe 从“内部代码能跑”做到了“在 QEMU AArch64 + Linux guest 里真的能打到用户态函数”。axebpf 侧补齐了 guest 用户态地址翻译、对象符号加载、hidden runtime observer、pending/active 管理，以及 EL0 BRK 命中后的 single-step 恢复；axvisor 侧接入了 guest-uprobe feature，并补上 trace uprobe / trace unuprobe / trace uloadelf / trace list 命令和对应的 VMM hook。现在 guest uprobe 已经不只是能挂一个pending 项，而是能在真实 Linux guest 用户态路径上完成激活和命中。
• guest 运行时状态链路补齐：为了让 Linux guest uprobe 的 runtime observer 真正工作起来，这周在axvm / arm_vcpu 侧补齐并缓存了 TTBR0_EL1、CONTEXTIDR_EL1、TPIDR_EL0 等 guest exit state；底层依赖侧也补上了 executable guest mappings 和 tracing symbol sections 导出。这样 Hypervisor 侧已经能拿到 Linux guest 用户态地址空间和进程上下文所需的关键状态。
• guest-kprobe 路径继续收口：修复了 guest-kprobe 命中后 single-step 还可能卡在执行权限窗口的问题，同时在 notify_guest_vmexit() 中自动尝试启用 deferred guest-kprobe。这样一来，guest-kprobe命中后的恢复链路更稳了，attach 时序也没有之前那么挑。
• 观测和交互体验改进：一是压低了 guest-kprobe 热点路径的日志噪声，并补了命中进度输出；二是修掉了 trace stream -n 在指定事件数量后还会轮询键盘输入的问题；三是把 shell 线程移到非 boot CPU，减少 host shell 对 guest tracing 观测的干扰。现在脚本化验证和日志分析都顺手不少。
• VMM 配置补充：修复 guest cmdline 透传，VM 配置转换时不再丢失 guest 启动参数。Linux guest 的验证配置和用户态程序自启动路径现在可以按预期带进去。

待完善:

• Linux guest uprobe 的一键验证流程还需要继续固化，guest-uprobe 的稳定性也需要在更多 fresh run下继续验证。
• uretprobe / 返回探针在 Linux guest 用户态的可行性还没展开，后续还需要继续评估返回地址维护方式和风险边界。
• guest-uprobe 目前重点还是主程序 userspace tracing，后续还需要继续评估共享库、dlopen、多进程 / 多 mm 等场景下的扩展方案。

[Iscreamx]

3.23 - 3.29

这周主要还是继续收口 Linux guest 用户态探针，重点放在 guest-uprobe/guest-uretprobe 的返回探针、实例隔离和 shell 可观测性上。到这一步，这条链路已经不只是“能注册一个 probe”，而是开始具备按 mm/pid/tgid 区分实例、按进程清理状态，以及在 trace list 里直接看到 active 实例上下文的能力。主程序场景下的基础 ASLR 适配和返回探针主路径也已经基本可用。不过边界也很明确：现在的对象模型还停留在主程序文本段这一层，共享库、多对象映射和 dlopen 带来的完整动态装载语义还没有进主线，所以这周的重点还是先把主程序场景做稳，而不是继续往共享库方向扩展。

[Iscreamx]

3.30 - 4.12

这两周先把共享库 uprobe/uretprobe 的问题边界看清了。现在真正卡住的，不是 load bias 或重定位公式本身，而是 runtime observer 在共享对象场景下还不能稳定完成对象路径和实例识别。实际现象是：dlopen 之后，guest 侧的共享库已经完成映射，目标函数也确实被执行了，但 host 侧没有把这次映射识别成能和 pending binding 对上的目标对象，结果 probe 一直停在 pending，共享库实例进不了 active。在这个前提下，这两周没有再继续往共享库方向扩功能，而是把重点转到主线联调上，集中把 tracepoint、hprobe/hretprobe、guest-kprobe/kretprobe、guest-uprobe/uretprobe 放进同一条QEMU + AxVisor + Linux guest 验证流程里，同时补齐统一 guest demo、rootfs 注入、自动化验收脚本、人工手工演示手册和配套文档。到目前为止，主线七类能力已经可以在一次运行窗口里统一验证, 当前这轮联调更多还是做到关键日志和关键命中结果可稳定输出，离正式对外演示还有一段距离，后面还需要继续打磨演示流程、日志呈现和操作节奏。