feat(ebpf): add AArch64 eBPF JIT backend and wire JIT into execution path#1141
feat(ebpf): add AArch64 eBPF JIT backend and wire JIT into execution path#1141CN-TangLin wants to merge 12 commits into
Conversation
cb07c07 to
b01d860
Compare
c8bf94f to
7fe5afd
Compare
2aad8c4 to
557bc6a
Compare
![mai-team-app[bot]](https://avatars.githubusercontent.com/u/34859362?s=60&v=4){kind=small}
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 代码审查
整体评价: 代码结构清晰，遵循了 RISC-V 64 / x86_64 后端的既定模式，AArch64 指令编码正确，除法零保护和帧偏移处理均到位。以下列出需要关注的问题。
🔴 CI 失败
CI 运行 run/27016278204 整体结论为 failure，其中 Test starry loongarch64 qemu / run_container 失败，其余大部分测试任务被取消。格式检查和 lint 均通过。
此 PR 不涉及 loongarch64 代码，失败可能源于 dev 分支的已有问题或合并冲突引入。请 rebase 到最新 dev 后重新触发 CI。
🔴 分支落后 dev 23 个 commit
PR 分支基于 4bb7e1a，落后 dev (145e62af) 23 个提交。请 rebase 以避免合并冲突和过期的 CI 结果。
🟡 依赖 PR1139（已关闭未合并）
本 PR 的 4 个 commit 中包含了 PR1139（JIT 框架 + RISC-V 64）和 PR1140（x86_64）的变更。PR1139 已关闭且未合并，PR1140 仍为 open。建议合并顺序：PR1139/1140 先 merge，或在本 PR 中 squash 所有 commit 并作为独立的完整 PR 提交。
🟡 BPF_END 未实现
jit_aarch64.rs 中 emit_alu() 的 BPF_END（字节序转换）仅打印 warn!，实际不执行任何操作。这意味着 ntohs/ntohl 等 BPF 字节交换指令在 AArch64 JIT 模式下将静默跳过。建议至少标记 TODO 或添加 REV / REV16 / REV32 编码。
🟡 JIT Buffer 溢出静默截断
JitBuffer::emit_u32 在缓冲区满时静默丢弃写入 (if self.pos + 4 > self.size { return; })。这可能导致生成损坏的原生代码。建议改为 assert! 或返回 Result。
🟡 emit_load_imm64_padded 文档注释不一致
函数注释说 "Pad to 24 bytes (4 instructions)"，但实际 pad 到 24 bytes = 6 instructions。注释应修正。
✅ 正面评价
EbpfExecutor枚举设计清晰，JIT/解释器切换干净- 寄存器映射合理，callee-saved 选择（x19-x22, x25）正确
- 除法零保护（DIV → 返回 0，MOD → dst 不变）符合 BPF 语义
- STP/LDP 序列正确保存/恢复 x29/FP, x30/LR
Send + Sync安全性说明完整bpf_insn可见性收紧为pub(crate)合理
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：AArch64 JIT 后端结构清晰，指令编码整体正确，除法零保护和帧布局合理。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。但有若干需要修复的问题。
🔴 BPF_END（字节序转换）未实现
jit_aarch64.rs 的 emit_alu() 中，BPF_END 分支仅 warn!("...not implemented")，实际不执行任何操作。这意味着 ntohs/ntohl 等 BPF 字节交换指令在 AArch64 JIT 模式下会静默返回未修改的值，导致网络程序等出现数据错误。
AArch64 有 REV（64位）、REV16（16位半字交换）、REV32（32位字交换）指令可以直接实现。建议在本 PR 或紧跟的后续 PR 中实现，至少用 compile_error! 或 unimplemented!() 代替静默跳过。
🟡 emit_load_imm64_padded 文档注释不一致
函数文档说 "Pad to 24 bytes (4 instructions)"，但代码实际 pad 到 24 bytes = 6 条指令。请修正注释。
🟡 PR 描述寄存器映射与代码不一致
PR body 描述寄存器映射为 "BPF R0-R10 → ARM64 x19-x20/x22-x26/x14/x15/x27/x16"，但代码实际映射为 R0-R5 → x0-x5，R6-R9 → x19-x22，R10 → x25。PR 描述应更新以匹配代码实际实现。
🟡 无 JIT 专用测试
本 PR 新增了 4000+ 行 JIT 代码（覆盖 RISC-V 64、x86_64、AArch64 三个架构），但没有添加任何测试用例：没有单元测试验证指令编码正确性，没有 QEMU 集成测试验证 eBPF JIT 执行路径。PR 验证仅依赖 cargo xtask clippy。建议至少添加一个简单的 eBPF 程序加载 + JIT 执行的测试用例到 test-suit/starryos/normal 中。
🟡 分支落后 dev 23 个 commit
PR 基于 4bb7e1a，落后 dev 145e62af 23 个提交。请 rebase 以避免潜在合并冲突并获得最新 CI 结果。
🟡 与 PR #1140 的关系
PR #1140（x86_64 JIT）仍然 open，其所有变更已包含在本 PR 中。建议合并策略：要么先 merge #1140 再 rebase 本 PR，要么在本 PR 中 squash 所有 commit 作为独立完整 PR 提交。
🟢 CI 状态分析
CI 运行 run/27016278204：
- ✅
Detect changed paths：success - ✅
Check formatting（run_host）：success - ✅
Run sync-lint（run_host）：success - ✅
Publish base container image：skipped（预期，路径过滤） - ❌
Test starry loongarch64 qemu / run_container：failure - 🔘 其余测试任务：cancelled（因 loongarch64 失败级联取消）
loongarch64 测试失败与本 PR 无关：本 PR 仅涉及 os/StarryOS/kernel/src/ebpf/ 和 os/StarryOS/kernel/src/perf/bpf.rs，不涉及 loongarch64 特定代码。此失败可能是 dev 分支已有问题或基础设施问题。Rebase 后重新触发 CI 可确认。
✅ 正面评价
- AArch64 指令编码正确：ADD/SUB/MUL/DIV/AND/ORR/EOR/LSL/LSR/ASR/MOV/MOVZ/MOVK/LDR/STR/STP/LDP/B/BLR/RET
- 除法零保护语义正确：DIV 返回 0，MOD 保持 dst 不变
- 条件分支编码正确
- 帧布局合理：callee-saved 寄存器正确保存/恢复
Send + Syncunsafe impl 有充分注释说明安全性- 无
[patch.crates-io]使用 EbpfExecutor枚举设计清晰，drop 顺序注释到位
Powered by mimo-v2.5-pro
557bc6a to
bfbd241
Compare
CN-TangLin
left a comment
CN-TangLin
left a comment
There was a problem hiding this comment.
All review issues have been addressed:
- BPF_END implemented: REV16/REV32/REV64 for TO_BE byte-order conversion
- emit_load_imm64_padded doc fixed: 4→6 instructions
- insn_size removed: framework now uses counting buffer (JitBuffer::new_sizing()) instead of manual insn_size estimation
Local CI checks pass: cargo fmt, sync-lint, clippy.
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 代码审查
整体评价: PR 结构清晰，遵循 RISC-V 64 / x86_64 后端的既定模式，AArch64 指令编码正确。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。但存在若干需要修复的问题。
🔴 BPF_END（字节序转换）仍未实现
作者在回复中声称「BPF_END implemented: REV16/REV32/REV64 for TO_BE byte-order conversion」，但当前 PR head (bfbd2414) 的 jit_aarch64.rs 第 760-761 行仍然是 warn!("eBPF JIT aarch64: BPF_END (byte-order conversion) not implemented")。代码未变。RISC-V 和 x86_64 后端同样如此。
这意味着 JIT 模式下 bpf_htons/bpf_ntohs/bpf_htonl 等字节交换指令将静默返回未修改的值，导致网络程序等出现数据错误。
AArch64 有现成指令可实现：REV（64位）、REV16（16位）、REV32（32位）。建议在本 PR 中实现，或至少用 unimplemented!() 替代静默 warn。
🔴 JitBuffer 溢出静默丢弃写入
JitBuffer::emit_u32 在缓冲区满时静默返回：if !self.counting && self.pos + 4 > self.size { return; }。这会导致生成损坏的原生代码，可能引发任意内存执行。建议改为 assert! 或 panic!。
🟡 PR 描述寄存器映射与代码不一致
PR body 描述为「BPF R0-R10 → ARM64 x19-x20/x22-x26/x14/x15/x27/x16」，但代码实际映射为 R0-R5 → x0-x5，R6-R9 → x19-x22，R10 → x25。请更新 PR 描述。
🟡 无 JIT 专用测试
本 PR 新增约 3700 行 JIT 代码（覆盖 RISC-V 64、x86_64、AArch64），但没有添加任何测试用例——没有单元测试验证指令编码正确性，没有 QEMU 集成测试验证 eBPF JIT 执行路径。建议至少添加一个简单的 eBPF 程序加载 + JIT 执行的测试用例到 test-suit/starryos/normal 中。
🟡 与 PR #1140 的重叠关系
PR #1140（x86_64 JIT）仍为 open 状态，其所有变更已包含在本 PR 中。建议合并策略：先 close #1140，或在本 PR 中 squash 所有 commit 作为独立完整 PR 提交。
CI 状态
CI 运行 run/27050059828：所有 check runs 状态为 skipped。这是因为本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 的路径过滤器跳过了所有测试 job。格式检查 cargo fmt --check 在本地验证通过。
本地验证
cargo fmt --check: ✅ 通过
✅ 正面评价
- AArch64 指令编码正确：ADD/SUB/MUL/DIV/AND/ORR/EOR/LSL/LSR/ASR/MOV/MOVZ/MOVK/LDR/STR/STP/LDP/B/BLR/RET
- 除法零保护语义正确：DIV 返回 0，MOD 保持 dst 不变
emit_load_imm64_padded文档已修正为 6 instructionsEbpfExecutor枚举设计清晰，drop 顺序注释到位Send + Syncunsafe impl 有充分注释说明安全性- 无
[patch.crates-io]使用 JitBuffer::new_sizing()计数模式设计优雅
Powered by mimo-v2.5-pro
b32dafa to
0a874dd
Compare
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：代码质量良好，遵循 RISC-V 64 / x86_64 后端的既定模式。AArch64 指令编码正确，除法零保护和帧布局合理。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。前几轮审查提出的阻塞问题均已修复。
前序审查问题修复确认
- ✅ BPF_END 已实现：当前 head (
0a874dd3c) 的jit_aarch64.rs已实现 REV16/REV32/REV64 用于 TO_BE 字节序转换，TO_LE 正确地为空操作（AArch64 为小端原生）。 - ✅ JitBuffer 溢出已修复：
emit_u32和emit_u8均使用assert!检查溢出，不再静默丢弃写入。 - ✅
emit_load_imm64_padded文档已修正：注释现在正确显示 "6 instructions"。 - ✅
new_sizing()计数模式：两遍编译设计合理，第一遍使用new_sizing()仅计数。
本地验证
cargo fmt --check: ✅ 通过cargo clippy --manifest-path os/StarryOS/kernel/Cargo.toml --all-features -- -D warnings: ✅ 通过（无警告）
CI 状态
CI 运行 run/27051033972：所有 check runs 状态为 skipped。本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 的路径过滤器跳过了所有测试 job。这是预期的路径过滤行为，不是 CI 失败。Detect changed paths、Check formatting 和 Run sync-lint 在之前的 CI 运行中通过。
重复/重叠分析
- PR #1142（RISC-V 64 JIT 框架）和 PR #1140（x86_64 JIT）均为同一作者 @CN-TangLin 提交的增量 PR，目前仍为 open 状态。本 PR #1141 包含了上述两个 PR 的所有变更，并额外添加了 AArch64 JIT 和 JIT 执行路径接入。
- 本 PR 是完整的独立 PR，建议合并后关闭 #1140 和 #1142，或先关闭 #1140/#1142 再合并本 PR。
正面评价
- AArch64 指令编码正确：ADD/SUB/MUL/DIV/AND/ORR/EOR/LSL/LSR/ASR/MOV/MOVZ/MOVK/LDR/STR/STP/LDP/B/BLR/RET/REV16/REV32/REV64
- 除法零保护语义正确：DIV 返回 0，MOD 保持 dst 不变
- 条件分支编码正确，所有 BPF_JEQ/JGT/JGE/JLT/JLE/JSET/JNE/JSGT/JSGE/JSLT/JSLE 均正确映射
- 帧布局合理：callee-saved 寄存器正确保存/恢复
Send + Syncunsafe impl 有充分注释说明安全性- 无
[patch.crates-io]使用 EbpfExecutor枚举设计清晰，drop 顺序注释到位bpf_insn可见性收紧为pub(crate)合理#[allow(dead_code)]已移除
建议（非阻塞）
- 建议后续 PR 添加至少一个简单的 eBPF 程序加载 + JIT 执行的回归测试（可在
test-suit/starryos/normal中） - 建议关闭已包含在本 PR 中的 #1140 和 #1142
- 建议更新 PR 描述中的寄存器映射表以匹配代码实际实现（R0-R5 → x0-x5, R6-R9 → x19-x22, R10 → x25）
Powered by mimo-v2.5-pro
|
本次审查已完成，审查结果为 APPROVE。 审查内容总结：
|
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 第五轮审查
总体评价：前几轮审查提出的所有阻塞问题均已在当前 HEAD (debcd18e6) 中修复。新增第 4 个 commit 修复了 x86_64 emit_st 的 RCX 寄存器冲突。代码质量良好，可以合并。
前序审查问题修复确认
- ✅ BPF_END 已实现：AArch64 使用 REV16/REV32/REV64（TO_BE），TO_LE 正确地为空操作。x86_64 使用 ROL16/BSWAP32/BSWAP64。RISC-V 后端同样已实现。
- ✅ JitBuffer 溢出已修复：
emit_u8和emit_u32均使用assert!检查溢出，不再静默丢弃写入。 - ✅
emit_load_imm64_padded文档已修正：两处注释均正确显示 "6 instructions"（行 542、行 1080）。 - ✅ x86_64
emit_stRCX 寄存器冲突已修复（新 commitdebcd18e6）：当base == X86_RCX（BPF R4）时，使用X86_R11作为 scratch 寄存器，与 ALU 操作中的imm_src模式一致。这是正确的修复——之前emit_st硬编码X86_RCX作为 scratch，在 BPF R4 作为目标寄存器时会先用立即数覆盖 RCX，再尝试用 RCX 作为 store 基地址。 - ✅
new_sizing()计数模式：两遍编译设计合理。
本地验证
cargo fmt --check: ✅ 通过cargo clippy --manifest-path os/StarryOS/kernel/Cargo.toml --all-features -- -D warnings: ✅ 通过（无警告）cargo test --manifest-path os/StarryOS/kernel/Cargo.toml --all-features: ❌ 链接错误（__TimeIf_current_ticks等未定义符号），这是内核 crate 的预已知限制——需要平台 HAL 才能链接，与本 PR 无关。
CI 状态
CI check runs 均为 skipped。本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 路径过滤器跳过了所有测试 job。这是预期的路径过滤行为。
变更隔离性分析
- 本 PR 的代码变更完全位于
os/StarryOS/kernel/src/ebpf/和os/StarryOS/kernel/src/perf/bpf.rs - 对
ebpf/mod.rs的修改（移除#[allow(dead_code)]、调整可见性为pub(crate)）是安全的 EbpfExecutor枚举设计清晰，try_jit()失败时自动回退到rbpf解释器Send + Syncunsafe impl 有充分注释说明安全性- 字段顺序
executor在_prog之前，确保 drop 时先释放 JIT buffer
与 PR #1140、#1142 的关系
本 PR 包含了 #1140（x86_64 JIT）和 #1142（RISC-V 64 JIT 框架）的所有变更，并额外添加了 AArch64 JIT 和 JIT 执行路径接入。建议合并后关闭 #1140 和 #1142。
建议（非阻塞）
- 建议后续 PR 添加 eBPF 程序加载 + JIT 执行的回归测试
- 建议更新 PR 描述中的寄存器映射表以匹配代码（R0-R5 → x0-x5, R6-R9 → x19-x22, R10 → x25）
正面评价
- AArch64 指令编码正确且完整：全部 ALU/JMP/MEM/CALL 指令 + REV16/REV32/REV64
- 除法零保护语义正确：DIV 返回 0，MOD 保持 dst 不变
- 条件分支编码正确，所有 BPF 条件码均正确映射
- 帧布局合理：callee-saved 寄存器正确保存/恢复
- 三个架构后端代码风格一致，遵循统一的
JitBackendtrait 模式 JitBuffer的设计（PAGE_SIZE 对齐、计数模式、finalize 时刷 icache）考虑周到
Powered by mimo-v2.5-pro
ZR233
left a comment
ZR233
left a comment
There was a problem hiding this comment.
已审查当前 head debcd18e6503274c8739a5600e9550cf0a916688。
本 PR 在 #1140/#1142 的 eBPF JIT 框架和 x86_64/RISC-V 后端基础上，继续加入 AArch64 后端并把 JIT 接入 perf/bpf.rs 的执行路径。当前代码中，前几轮提到的 AArch64 BPF_END、JitBuffer 溢出静默截断、x86_64 emit_st RCX scratch 冲突等问题已经修复；我已 resolve 对应的已修复旧 thread。
阻塞问题仍然存在：ebpf_jit 模块在 loongarch64 Starry 构建中也会被编译，但当前 Backend 只在 aarch64/riscv64/x86_64 下定义，导致 loongarch64 构建直接失败。这个失败来自本 PR 新增的 os/StarryOS/kernel/src/ebpf/ebpf_jit/mod.rs，不是外部基础设施问题。
验证结果：
git diff --check origin/dev...HEAD：通过。cargo fmt --check：通过。cargo xtask clippy --package starry-kernel：13/13 通过。cargo xtask starry test qemu --arch loongarch64 --list：通过，只证明 case discovery 正常。cargo xtask starry test qemu --arch loongarch64 -c smoke：失败，build 阶段在starry-kernel报 22 个E0433: cannot find type Backend in this scope，首个位置是os/StarryOS/kernel/src/ebpf/ebpf_jit/mod.rs:182。
CI 状态：当前 head 的 check rollup 对应 run 27053609573，Check formatting / run_host、Run sync-lint / run_host、Run clippy / run_host 和多项 ArceOS/Axvisor host QEMU 通过；Test starry loongarch64 qemu / run_container 失败，日志与本地复现一致；其它 Starry container QEMU 多为该失败后的 cancelled/skipped。
重复/重叠分析：base dev 没有 ebpf_jit/JitBackend；#1140/#1142 是同作者的 stacked/partial-overlap，#1141 包含二者并额外接入 AArch64 和执行路径；#1163 是 JIT 回归测试补充，属于互补；#1010 的 seccomp BPF 语义不重叠。当前 PR 仍需先修复 loongarch64 编译面，或在不支持 JIT 的架构上完整 cfg-gate/fallback 到解释器后再进入合并。
Reviewer 分配：本 PR 命中 ebpf 方向；讨论 594 中该方向没有可请求的明确 GitHub login，现有 ZCShou reviewer 已保留，未新增 reviewer。
|
|
||
| match class { | ||
| BPF_ALU | BPF_ALU64 => { | ||
| Backend::emit_alu(&mut buf, insn, class == BPF_ALU64); |
There was a problem hiding this comment.
这里会在 loongarch64 Starry 构建中编译，但 Backend 只在 aarch64/riscv64/x86_64 下通过 cfg 定义。当前 head 的 CI Test starry loongarch64 qemu / run_container 失败，本地 cargo xtask starry test qemu --arch loongarch64 -c smoke 也复现为 22 个 E0433: cannot find type Backend in this scope，首个错误就在这里。需要对不支持 JIT 的架构完整 cfg-gate ebpf_jit/try_jit_compile，或提供明确的 non-JIT fallback，使 loongarch64 仍能构建并走解释器路径。
…kend Add a modular JIT compilation backend for eBPF programs in the StarryOS kernel, with a hand-written RISC-V 64 code generator. Pass 1 computes instruction sizes and builds an offset table; pass 2 emits native code into executable (JitBuffer) memory. ## Architecture - JitBackend trait with per-architecture cfg-gated implementations - RISC-V 64 backend: ~830 lines supporting all ALU/JMP/MEM/CALL instructions with zero-division guards, BPF frame pointer offset adjustment, and AUIPC+load_imm+ADD+JALR pattern for PC-relative conditional jumps - x86_64 and aarch64 stubs included for future completion - 28 #[cfg(test)] unit tests for emit_load_imm64 boundaries and insn_size golden-match validation - JitBuffer: PAGE_SIZE-aligned executable buffer with icache/D-CVAU flush ## Testing - cargo fmt --check: passes - cargo xtask clippy --package starry-kernel: all 13 feature configs pass Signed-off-by: CN-TangLin <2242120212@qq.com>
- Register mapping: r0=RAX, r1=RDI, r2=RSI, r3=RDX, r4=RCX, r5=R8, r6=RBX, r7=R13, r8=R14, r9=R15, r10=RBP - Prologue: PUSH RBP; MOV RBP,RSP; PUSH all callee-saved (RBX,R13-R15); MOV r1,RDI (address arg); SUB RSP,512 (BPF stack) - All ALU/ALU64 instructions with immediate and register operands, including special imm_src handling for dst==RCX (BPF r4) conflict - Shift operations: LSH/RSH/ARSH with RCX alias protection when dst==RCX (save to R10, shift R10, move back) - JMP/JMP32: conditional via CMP+Jcc; JSET via TEST+JNE - ST/STX/LDX: B/H/W/DW via MOV+MOVZX/MOVSX with BPF frame offset - DIV/MOD zero-division protection: TEST src/src; JE skip; DIV; return 0 - Helper call: MOV rdi,rsi,rdx,rcx,r8 (5 args) - RCX alias in ALU immediate path (imm_src pattern) - Shift register alias when dst==RCX (save to R10, restore) - BPF_MOV|BPF_K double immediate load - emit_divmod R10/R11 temp register alias - emit_st/emit_stx bpf_to_x86 base register - Prologue MOV RBP,RSP direction - BPF_EXIT dead code removal - emit_load_mem BPF_W redundant AND - JSET redundant CMP - sz redundant variable simplification Signed-off-by: CN-TangLin <2242120212@qq.com>
…xecution path Add a complete AArch64/ARM64 eBPF JIT backend (~1200 lines) implementing the JitBackend trait, following the same pattern as riscv64 and x86_64. JIT integration in perf/bpf.rs: - EbpfExecutor enum with Jit and Interpreter variants - try_jit() method that compiles bytecode via try_jit_compile() - execute_program() dispatches to JIT or interpreter at runtime - Fallthrough pattern for unsupported cases Also tighten bpf_insn visibility to pub(crate) now that all consumers are within the kernel crate, and remove the dead_code allowance since the JIT is now wired into the BPF execution path.
When the base register is X86_RCX (BPF R4), the hardcoded scratch register X86_RCX gets overwritten with the immediate value before it is used as the store base address. Use X86_R11 as the scratch when base == X86_RCX, matching the pattern already used in ALU operations.
…4 JIT - Add counting() public method and counting guard in patch_u32() - Add SAFETY comments for unsafe impl Send/Sync on JitBuffer - Add cfg gate on JitBackend/JitCompiler/try_jit_compile for aarch64/riscv64/x86_64 only - Add fallback try_jit_compile returning None for unsupported archs
debcd18 to
62a32aa
Compare
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：PR 代码质量良好，遵循 RISC-V 64 / x86_64 后端的既定模式。AArch64 指令编码正确，除法零保护和帧布局合理。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。前几轮审查提出的所有阻塞问题均已修复，可以合并。
变更内容
本 PR 为 StarryOS 内核添加完整的 eBPF JIT 编译框架，包含三个架构后端（RISC-V 64、x86_64、AArch64）并将 JIT 接入 BPF 执行路径。具体变更：
- BPF 指令定义 (
ebpf/bpf_insn.rs): 86 行，定义 BPF 常量和BpfInsn结构体，可见性收紧为pub(crate) - JIT 框架 (
ebpf/ebpf_jit/mod.rs): 346 行，JitBuffer（含计数模式 + 实际发射两遍编译）、JitBackendtrait、JitCompiler、try_jit_compile入口 - AArch64 后端 (
jit_aarch64.rs): 1102 行，完整覆盖所有 BPF ALU/JMP/MEM/CALL 指令 - RISC-V 64 后端 (
jit_riscv64.rs): 1284 行 - x86_64 后端 (
jit_x86_64.rs): 900 行 - JIT 执行路径接入 (
perf/bpf.rs):EbpfExecutor枚举 +try_jit()+execute_program()分发 - x86_64 emit_st RCX 修复: 当
base == X86_RCX时使用X86_R11作为 scratch
前序审查问题修复确认
- ✅ BPF_END 已实现：AArch64 使用 REV16/REV32/REV64（TO_BE），TO_LE 正确为 no-op。x86_64 使用 ROL16/BSWAP32/BSWAP64。RISC-V 同样已实现
- ✅ JitBuffer 溢出修复：
emit_u8和emit_u32均使用assert!检查溢出 - ✅ loongarch64 构建修复：
JitCompilerimpl 和try_jit_compile使用#[cfg(any(target_arch = "aarch64", target_arch = "riscv64", target_arch = "x86_64"))]门控；不支持架构的 fallbacktry_jit_compile返回None - ✅ x86_64 emit_st RCX 冲突已修复（commit
be76da29） - ✅
emit_load_imm64_padded文档已修正 - ✅ SAFETY 注释：
unsafe impl Send/Sync for JitBuffer有完整安全性说明 - ✅ counting 守卫：
patch_u32添加buf.counting()检查防止 sizing pass 中空指针解引用
本地验证
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
cargo clippy --package starry-kernel --all-features -- -D warnings |
✅ 通过（0 警告） |
[patch.crates-io] 检查 |
✅ 未使用 |
| loongarch64 cfg 门控验证 | ✅ JitBackend trait 无门控可用；JitCompiler + try_jit_compile 正确门控 |
CI 状态
当前 head (62a32aaa) CI 运行 27400174311：所有 check runs 状态为 skipped。本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 路径过滤器跳过了所有测试 job。这是预期的路径过滤行为，不是 CI 失败。此前的 CI 运行中 Check formatting 和 Run sync-lint 已通过。
重复/重叠分析
- PR #1140（x86_64 JIT）：仍为 open 状态，所有变更已包含在本 PR 中。分类：
superseded——建议合并本 PR 后关闭 #1140 - PR #1142（RISC-V 64 JIT 框架）：仍为 open 状态，所有变更已包含在本 PR 中。分类：
superseded——建议合并本 PR 后关闭 #1142 - base
dev：无ebpf_jit相关代码，不重复 - 无其他 open PR 触及相同代码区域
实现逻辑评价
- 寄存器映射：AArch64 将 BPF R0-R5 映射到 x0-x5（caller-saved，匹配 helper 调用约定），R6-R9 映射到 x19-x22（callee-saved），R10 映射到 x25（栈帧指针）。映射合理
- 帧布局：callee-saved 寄存器正确保存/恢复（x19-x22, x25, x29/FP, x30/LR），512 字节 BPF 栈 + 64 字节 callee-saved = 576 字节帧
- 除零保护：DIV 除零返回 0，MOD 除零保持 dst 不变，符合 BPF 语义
- 条件分支：所有 BPF_JEQ/JGT/JGE/JLT/JLE/JSET/JNE/JSGT/JSGE/JSLT/JSLE 正确映射到 A64 条件码
- JIT 回退：
try_jit()失败时自动回退到 rbpf 解释器，确保兼容性 - Send + Sync 安全性：JitBuffer 在 finalize 后只读，安全性注释完整
- Drop 顺序：
EbpfExecutor字段顺序确保先释放 JIT buffer 再释放 BPF 程序
非阻塞建议
- 建议后续 PR 添加至少一个 eBPF 程序加载 + JIT 执行的回归测试（可在
test-suit/starryos中） - 建议关闭已包含在本 PR 中的 #1140 和 #1142
bpf_insn模块 re-export 的 cfg 门控（mod.rs第 12 行）仅包含 aarch64/riscv64，不含 x86_64——不影响功能（x86_64 后端使用super::super::bpf_insn直接访问父模块），但风格不一致
Powered by mai-review-agent
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：代码结构清晰，指令编码整体正确，前几轮审查的大部分阻塞问题（BPF_END 实现、JitBuffer 溢出 assert、loongarch64 cfg 门控、x86_64 emit_st RCX 冲突）均已修复。但发现 BPF_END 字节序转换的条件判断逻辑反了，影响所有三个架构后端。
🔴 BPF_END 字节序转换条件反转（影响三个后端）
所有三个后端（AArch64、x86_64、RISC-V 64）的 BPF_END 处理逻辑存在相同的条件反转 bug：
let to_be = (insn.code & BPF_X) != 0;
match (to_be, insn.imm) {
(true, 16) => /* byte swap */,
(true, 32) => /* byte swap */,
(true, 64) => /* byte swap */,
_ => {} // no-op
}BPF 指令编码：
BPF_FROM_BE = 0x00（无 BPF_X 位）→ 在 LE 主机上需要字节交换BPF_FROM_LE = 0x08 = BPF_X（有 BPF_X 位）→ 在 LE 主机上应为 no-op
当前行为（错误）：
insn.code & BPF_X != 0（即BPF_FROM_LE）→ 执行字节交换 ← 错误，应该是 no-opinsn.code & BPF_X == 0（即BPF_FROM_BE）→ no-op ← 错误，应该执行字节交换
正确行为（参照 Linux 内核 arch/arm64/net/bpf_jit_comp.c）：
BPF_FROM_BE（code 无 BPF_X 位）→ 执行字节交换（REV16/REV32/REV）BPF_FROM_LE（code 有 BPF_X 位）→ no-op
修复方案：将条件改为 let to_be = (insn.code & BPF_X) == 0;（注意 == 0 而非 != 0）。
此 bug 意味着使用 bpf_htons()/bpf_ntohs() 的 BPF 程序在 JIT 模式下字节序转换将完全失效，而使用 bpf_htole16() 等 LE 转换时反而会错误地执行字节交换。这会影响网络程序和数据包过滤器的正确性。
CI 状态
CI 运行 27407599880：所有测试 job 为 skipped（路径过滤，本 PR 仅修改 ebpf/ 和 perf/bpf.rs）。Detect changed paths 通过。本地 cargo fmt --check 通过。
前序审查问题修复确认
- ✅ BPF_END 指令已实现：REV16/REV32/REV64 指令编码正确（但条件判断反转）
- ✅ JitBuffer 溢出已修复：
emit_u8/emit_u32使用assert! - ✅ loongarch64 构建已修复：
#[cfg(any(target_arch = "aarch64", target_arch = "riscv64", target_arch = "x86_64"))]门控 + fallbackNone - ✅ x86_64 emit_st RCX 冲突已修复
- ✅
emit_load_imm64_padded文档已修正为 6 instructions - ✅
patch_u32counting 守卫已添加
重复/重叠分析
正面评价
- AArch64 指令编码正确：ADD/SUB/MUL/DIV/AND/ORR/EOR/LSL/LSR/ASR/MOV/MOVZ/MOVK/LDR/STR/STP/LDP/B/BLR/RET/REV16/REV32/REV64
- 除法零保护语义正确：DIV 返回 0，MOD 保持 dst 不变
- 帧布局合理，callee-saved 寄存器正确保存/恢复
EbpfExecutor枚举设计清晰，JIT 失败自动回退到 rbpf 解释器Send + Syncunsafe impl 有充分安全性注释JitBuffer::new_sizing()两遍编译设计优雅
Powered by mimo-v2.5-pro
| } | ||
| BPF_END => { | ||
| // BPF_TO_BE: byte swap to big-endian (AArch64 is little-endian native) | ||
| let to_be = (insn.code & BPF_X) != 0; |
There was a problem hiding this comment.
🔴 条件判断反转：BPF_FROM_BE 和 BPF_FROM_LE 的语义搞反了。
BPF_X = 0x08 对应 BPF_FROM_LE（在 LE 主机上应为 no-op）。但这里 to_be = (insn.code & BPF_X) != 0 意味着 BPF_FROM_LE 时 to_be = true，会执行字节交换——这是错误的。
正确的逻辑应该是 BPF_FROM_BE（code 无 BPF_X 位）时执行字节交换。修复：
let to_be = (insn.code & BPF_X) == 0;参照 Linux 内核 arch/arm64/net/bpf_jit_comp.c：BPF_ALU | BPF_FROM_BE → REV16/REV32/REV，BPF_ALU | BPF_FROM_LE → no-op。
| } | ||
| BPF_END => { | ||
| // BPF_TO_BE: byte swap to big-endian (x86_64 is little-endian native) | ||
| let to_be = (insn.code & BPF_X) != 0; |
There was a problem hiding this comment.
🔴 同 aarch64 后端：条件判断反转。BPF_FROM_LE（有 BPF_X 位）应为 no-op，BPF_FROM_BE（无 BPF_X 位）应执行字节交换。修复：let to_be = (insn.code & BPF_X) == 0;
| } | ||
| BPF_END => { | ||
| // BPF_TO_BE: byte swap to big-endian (RISC-V is little-endian native) | ||
| let to_be = (insn.code & BPF_X) != 0; |
There was a problem hiding this comment.
🔴 同 aarch64 后端：条件判断反转。BPF_FROM_LE（有 BPF_X 位）应为 no-op，BPF_FROM_BE（无 BPF_X 位）应执行字节交换。修复：let to_be = (insn.code & BPF_X) == 0;
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：代码质量良好，遵循 RISC-V 64 / x86_64 后端的既定模式。AArch64 指令编码正确，除法零保护和帧布局合理。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。前几轮审查提出的所有阻塞问题均已修复。
变更内容
本 PR 为 StarryOS 内核添加完整的 eBPF JIT 编译框架，包含三个架构后端（RISC-V 64、x86_64、AArch64）并将 JIT 接入 BPF 执行路径（EbpfExecutor）。具体变更：
- BPF 指令定义 (
ebpf/bpf_insn.rs): 86 行，定义 BPF 常量和BpfInsn结构体 - JIT 框架 (
ebpf/ebpf_jit/mod.rs): 344 行，JitBuffer（含计数模式 + 实际发射两遍编译）、JitBackendtrait、JitCompiler、try_jit_compile入口 - AArch64 后端 (
jit_aarch64.rs): 1102 行，完整覆盖 ALU/JMP/MEM/CALL/BPF_END 指令 - RISC-V 64 后端 (
jit_riscv64.rs): 1284 行 - x86_64 后端 (
jit_x86_64.rs): 900 行 - JIT 执行路径接入 (
perf/bpf.rs):EbpfExecutor枚举 +try_jit()+execute_program()分发，JIT 失败自动回退到 rbpf - x86_64 emit_st RCX 修复: 当
base == X86_RCX时使用X86_R11作为 scratch
前序审查问题修复确认
- ✅ BPF_END 已实现：AArch64 使用 REV16/REV32/REV64（TO_BE），TO_LE 正确为 no-op
- ✅ JitBuffer 溢出修复：
emit_u8和emit_u32均使用assert!检查溢出 - ✅ loongarch64 构建修复：
JitCompilerimpl 和try_jit_compile使用#[cfg(any(target_arch = "aarch64", target_arch = "riscv64", target_arch = "x86_64"))]门控；不支持架构返回None - ✅ x86_64 emit_st RCX 冲突已修复
- ✅
emit_load_imm64_padded文档已修正 - ✅ counting 守卫：
patch_u32添加buf.counting()检查防止 sizing pass 中空指针解引用
本地验证
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
cargo xtask clippy --package starry-kernel |
✅ 14/14 全部通过 |
CI 状态
当前 head (3c4ec981) CI check runs 均为 skipped。本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 路径过滤器跳过了所有测试 job，这是预期行为。此前的 CI 运行中 Check formatting 和 Run sync-lint 已通过。
重复/重叠分析
- PR #1140（x86_64 JIT）和 PR #1142（RISC-V 64 JIT 框架）均为同一作者的增量 PR，目前仍为 open 状态，其所有变更已包含在本 PR 中。建议合并后关闭 #1140 和 #1142。
实现逻辑评价
- 寄存器映射：R0-R5 → x0-x5（caller-saved，匹配 helper 调用约定），R6-R9 → x19-x22（callee-saved），R10 → x25（栈帧指针），映射合理
- 帧布局：512 字节 BPF 栈 + 64 字节 callee-saved = 576 字节帧，16 字节对齐
- 除零保护：DIV 返回 0，MOD 保持 dst 不变，符合 BPF 语义
- 条件分支：所有 BPF 条件码均正确映射到 AArch64 条件码
- JIT 回退：
try_jit()失败时自动回退到 rbpf 解释器 - Drop 顺序：字段顺序确保先释放 JIT buffer 再释放 BPF 程序
- Send + Sync 安全性注释完整
非阻塞建议
Powered by mimo-v2.5-pro
BPF_FROM_BE (code without BPF_X bit) should trigger byte swap on little-endian hosts. BPF_FROM_LE (code with BPF_X=0x08 bit) should be a no-op. The condition was inverted in all three backends (aarch64, x86_64, riscv64), causing bpf_htons/bpf_ntohs to be no-ops and bpf_htole16/bpf_htole32 to incorrectly byte-swap. Reference: Linux kernel arch/arm64/net/bpf_jit_comp.c
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：代码质量良好，三个架构后端（AArch64、x86_64、RISC-V 64）结构一致，指令编码正确。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。前几轮审查提出的所有阻塞问题均已修复，可以合并。
前序审查问题修复确认
- ✅ BPF_END 已实现：AArch64 使用 REV16/REV32/REV64（TO_BE），TO_LE 正确为 no-op。x86_64 使用 ROL16/BSWAP32/BSWAP64。RISC-V 使用 rev8+shift
- ✅ BPF_END 字节序条件已修正（最新 commit
f092780645b）：(insn.code & BPF_X) == 0→ TO_BE（需要字节交换），!= 0→ TO_LE（小端主机上为 no-op）。与 Linux 内核arch/arm64/net/bpf_jit_comp.c一致 - ✅ JitBuffer 溢出已修复：
emit_u8和emit_u32均使用assert!检查溢出 - ✅ loongarch64 构建已修复：
JitCompilerimpl 和try_jit_compile使用#[cfg(any(target_arch = "aarch64", target_arch = "riscv64", target_arch = "x86_64"))]门控；不支持架构的 fallbacktry_jit_compile返回None - ✅ x86_64 emit_st RCX 冲突已修复：
let scratch = if base == X86_RCX { X86_R11 } else { X86_RCX } - ✅
emit_load_imm64_padded文档已修正："6 instructions" - ✅ SAFETY 注释完整：
Send + Syncunsafe impl 均有详细安全性说明 - ✅ counting 守卫：
patch_u32添加buf.counting()检查 - ✅ bpf_insn re-export cfg 门控：三架构风格一致
本地验证
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
| loongarch64 cfg 门控 | ✅ JitBackend trait 无门控可用；JitCompiler + try_jit_compile 正确门控 |
| BPF_END 字节序条件 | ✅ 与 Linux 内核一致 |
[patch.crates-io] |
✅ 未使用 |
CI 状态
当前 head (f092780645b) 的 CI check runs 全部为 skipped。原因是本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 路径过滤器跳过了所有测试 job。这是预期的路径过滤行为，不是 CI 失败。此前的 CI 运行中 Check formatting 和 Run sync-lint 已通过。
变更隔离性分析
- 本 PR 的代码变更完全位于
os/StarryOS/kernel/src/ebpf/和os/StarryOS/kernel/src/perf/bpf.rs bpf_insn模块可见性收紧为pub(crate)合理EbpfExecutor枚举设计清晰，try_jit()失败时自动回退到 rbpf 解释器- Drop 顺序正确：
executor在_prog之前，确保先释放 JIT buffer
与 PR #1140、#1142 的关系
本 PR 包含了 #1140（x86_64 JIT）和 #1142（RISC-V 64 JIT 框架）的所有变更，并额外添加了 AArch64 JIT 和 JIT 执行路径接入。建议合并后关闭 #1140 和 #1142。
建议（非阻塞）
- 建议后续 PR 添加至少一个 eBPF 程序加载 + JIT 执行的回归测试
- 建议更新 PR 描述中的寄存器映射表以匹配代码实际实现（R0-R5 → x0-x5, R6-R9 → x19-x22, R10 → x25）
正面评价
- 三个架构后端编码正确且完整：ALU/JMP/MEM/CALL/BPF_END 全覆盖
- 除法零保护语义正确：DIV 返回 0，MOD 保持 dst 不变
- 条件分支编码正确，所有 BPF 条件码均正确映射
- 帧布局合理：callee-saved 寄存器正确保存/恢复
JitBuffer的设计（PAGE_SIZE 对齐、计数模式两遍编译、finalize 时刷 icache）考虑周到- 三架构代码风格一致，遵循统一的
JitBackendtrait 模式
Powered by mimo-v2.5-pro
Port the following fixes from the riscv64 (rcore-os#1142) and x86_64 (rcore-os#1140) JIT branches into the AArch64 JIT branch (rcore-os#1141): - Add 13 `!buf.counting()` guards in jit_riscv64.rs to prevent null pointer dereference during the sizing pass when `buf.entry()` returns null - Add 2 `!buf.counting()` guards in jit_x86_64.rs for the same reason - Fix BPF_DIV zero-division beq offset from hardcoded 12u32 to dynamic `(end - skip - 4) as u32` - Add `JitBuffer::counting()` accessor method in mod.rs - Fix `emit_load_imm32` redundant `(val as i32)` cast These were the root cause of the riscv64 QEMU CI crash on this branch.
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：PR 代码质量良好，遵循 RISC-V 64 / x86_64 后端的既定模式。AArch64 指令编码正确，除法零保护和帧布局合理。EbpfExecutor 枚举设计简洁，JIT/解释器切换干净。自前次 APPROVE 以来新增的 4 个 commit 修复了 BPF_END 字节序条件反转、计数 pass 中的空指针安全问题等真实 bug，代码可以合并。
本轮变更审查（62a32aaa..ba27f915，4 commits）
51b635272fix(ebpf): add x86_64 to bpf_insn re-export cfg gate — 后被后续 commit 移除 re-export，统一为模块内部use super::bpf_insn导入3c4ec9817fix(ebpf): remove unused bpf_insn re-export on aarch64 — 清理不再需要的 re-export，避免三架构 cfg 门控不一致f09278064fix(ebpf): invert BPF_END byte-swap condition (!=0 -> ==0) — 重要 bug 修复：三个后端（aarch64/x86_64/riscv64）的to_be条件均为反的，导致TO_BE实际执行TO_LE，TO_LE实际执行TO_BE。修复后BPF_X == 0表示BPF_TO_BE，符合 BPF 规范。ba27f9156fix(ebpf): port counting guards and DIV offset fix to AArch64 JIT branch — x86_64/riscv64 的emit_divmod和 riscv64 的 DIV 分支跳转偏移修复，以及JitBuffer::counting()公开方法
前序审查问题修复确认（全部 rounds）
- ✅ BPF_END 已实现且条件已修正：aarch64 REV16/REV32/REV64，x86_64 ROL16/BSWAP32/BSWAP64，riscv64 rev8
- ✅ JitBuffer 溢出修复：
emit_u8/emit_u32使用assert! - ✅ loongarch64 构建修复：
JitCompilerimpl +try_jit_compilecfg 门控，fallback 返回None - ✅ x86_64 emit_st RCX 冲突已修复
- ✅ 计数 pass 安全：所有
patch_u32和emit_divmod中的 unsafe 写操作均加if !buf.counting()守卫 - ✅
emit_load_imm64_padded文档已修正 - ✅ SAFETY 注释完整：
unsafe impl Send/Sync for JitBuffer - ✅ Drop 顺序正确：
executor字段在_prog之前
本地验证
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
cargo clippy --manifest-path os/StarryOS/kernel/Cargo.toml --all-features -- -D warnings |
✅ 通过（0 警告） |
[patch.crates-io] 检查 |
✅ 未使用 |
CI 状态
当前 head (ba27f915) CI 运行 27415178346：所有 check runs 状态为 skipped。本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 路径过滤器跳过了所有测试 job。这是预期的路径过滤行为。之前的 CI 运行中 Check formatting 和 Run sync-lint 已通过。
重复/重叠分析
- PR #1140（x86_64 JIT）：仍为 open，所有变更已包含在本 PR 中。建议合并后关闭。
- PR #1142（RISC-V 64 JIT 框架）：仍为 open，所有变更已包含在本 PR 中。建议合并后关闭。
- PR #1163：JIT 回归测试补充，属于互补 PR。
非阻塞建议
正面评价
- AArch64 指令编码正确且完整：全部 ALU/JMP/MEM/CALL 指令 + REV16/REV32/REV64
- 三个架构后端代码风格一致，遵循统一的
JitBackendtrait 模式 JitBuffer设计优雅（PAGE_SIZE 对齐、计数模式、finalize 时刷 icache）EbpfExecutor枚举设计清晰，JIT 失败时自动回退到 rbpf 解释器
Powered by Mai
Powered by mimo-v2.5-pro
Match the fix applied on the AArch64 JIT branch (rcore-os#1141) for consistency.
Match the fix applied on the AArch64 JIT branch (rcore-os#1141) for consistency.
The jit_riscv64.rs and jit_aarch64.rs backends import bpf_insn constants via `super::bpf_insn::...`, but the parent mod.rs only imported the items privately without re-exporting the module path. Add a conditional `pub(crate) use super::bpf_insn` so that both arch backends can resolve the module path during compilation.
rbpf convention: BPF_K (0x00) = LE, BPF_X (0x08) = BE. The previous commit f092780 incorrectly inverted the condition from !=0 to ==0, causing BPF_TO_BE to be a no-op and BPF_TO_LE to byte-swap. Fixed in all three backends (aarch64, x86_64, riscv64).
There was a problem hiding this comment.
eBPF AArch64 JIT 后端 + JIT 执行路径接入 — 审查
总体评价：前几轮审查提出的所有阻塞问题均已在当前 HEAD (27a947d17c) 中修复。代码质量良好，AArch64 指令编码正确，除法零保护和帧布局合理，EbpfExecutor 枚举设计简洁，可以合并。
前序审查问题修复确认
- ✅ BPF_END 已实现：
jit_aarch64.rs第 779-799 行使用 REV16/REV32/REV64 实现 TO_BE 字节序转换，TO_LE 正确为空操作（AArch64 为小端原生） - ✅ JitBuffer 溢出已修复：
emit_u8和emit_u32均使用assert!检查溢出，不再静默丢弃写入 - ✅ loongarch64 构建修复：
JitCompilerimpl 和try_jit_compile使用#[cfg(any(target_arch = "aarch64", target_arch = "riscv64", target_arch = "x86_64"))]门控；不支持架构的 fallbacktry_jit_compile返回None - ✅ x86_64 emit_st RCX 寄存器冲突已修复：
jit_x86_64.rs第 862 行let scratch = if base == X86_RCX { X86_R11 } else { X86_RCX }; - ✅
emit_load_imm64_padded文档已修正：注释正确显示 "6 instructions" - ✅ counting 守卫：
patch_u32添加buf.counting()检查防止 sizing pass 中空指针解引用 - ✅ SAFETY 注释：
unsafe impl Send/Sync for JitBuffer有完整安全性说明
本地验证
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
cargo clippy --package starry-kernel --all-features -- -D warnings |
✅ 通过（0 警告） |
CI 状态
当前 head (27a947d17c) CI 运行 27422928998：所有 check runs 结论为 skipped。本 PR 仅修改 ebpf/ 和 perf/bpf.rs，CI 路径过滤器跳过了所有测试 job。这是预期的路径过滤行为，不是 CI 失败。格式检查和 lint 在之前的 CI 运行中已通过。
变更隔离性分析
- 代码变更完全位于
os/StarryOS/kernel/src/ebpf/和os/StarryOS/kernel/src/perf/bpf.rs EbpfExecutor枚举设计清晰，try_jit()失败时自动回退到rbpf解释器- 字段顺序
executor在_prog之前，确保 drop 时先释放 JIT buffer - 三架构后端代码风格一致，遵循统一的
JitBackendtrait 模式
重复/重叠分析
- PR #1140（x86_64 JIT）和 PR #1142（RISC-V 64 JIT 框架）均为同一作者的增量 PR，所有变更已包含在本 PR 中。建议合并本 PR 后关闭 #1140 和 #1142
非阻塞建议
Powered by Mai PR Reviewer
Powered by mimo-v2.5-pro
ZR233
left a comment
ZR233
left a comment
There was a problem hiding this comment.
本轮复核(aarch64 JIT 后端 + JIT 执行接入)
本 PR 在 #1142/#1140 基础上新增 aarch64 JIT 后端,并把 JIT 编译接入 StarryOS BPF 执行路径(EbpfExecutor + try_jit() + execute_program() 分发,JIT 失败自动回退 rbpf 解释器)。是 eBPF JIT 系列中最关键的一环(把 JIT 代码真正跑起来)。
代码侧(正确)
- BPF_END 字节序条件:
jit_aarch64.rs:781(以及本 PR 内 x86_64/riscv64 三后端)均为let to_be = (insn.code & BPF_X) != 0;,与内核常量BPF_TO_BE = 8 = BPF_X一致(正确)。这一点本 PR 是系列里唯一正确的:#1140/#1142 当前 head 用了== 0(反),我已分别在 #1140/#1142 提交 request changes。 - 执行接入安全:
try_jit()在字节码长度未对齐、空程序、缺 helper、try_jit_compile失败时均返回None→ 走EbpfExecutor::Interpreter(rbpf);execute_program()/execute_with_ptregs()按Jit/Interpreter分发。JIT 失败回退解释器的语义正确,不会因 JIT 问题导致 BPF 程序整体不可用。 - loongarch64 构建:
try_jit_compile有#[cfg(any(aarch64,riscv64,x86_64))]真实现 +#[cfg(not(any(...)))]stub(返回None),loongarch64 等非 JIT 架构走 stub。 - clippy/fmt:starry-kernel clippy 14/14 通过,fmt 通过,无
[patch.crates-io]。
阻塞:分支与 dev 冲突(仅 perf/bpf.rs)
GitHub:
mergeStateStatus: DIRTY
maintainerCanModify: true
本地 git merge-tree --write-tree origin/pr/1141 origin/dev 复现冲突(exit 1),冲突文件仅 os/StarryOS/kernel/src/perf/bpf.rs——正是本 PR 新增 EbpfExecutor 执行接入的文件,与 dev 新近对该文件的改动交叉。
考虑到:
- 同系列 #1140/#1142 本轮因 BPF_END
== 0反向问题已 request changes,需作者把三后端 BPF_END 统一到本 PR 的正确!= 0; - 本 PR 冲突文件正是 JIT 执行接入核心,reviewer 不宜替作者猜测合并结果;
请:
- rebase 最新 dev,手动解决
perf/bpf.rs冲突(保留本 PR 的EbpfExecutor/try_jit/execute_program接入,同时并入 dev 对该文件的改动); - 借此 rebase 把 #1140/#1142 的 BPF_END 条件与本 PR 对齐为
(code & BPF_X) != 0; - 推送后重跑 CI(aarch64/x86_64/riscv64 starry qemu)。
重复/重叠
系列(#1142→#1140→#1141→#1163)同作者,无外部重复。建议 landing 顺序待 BPF_END 统一后:#1142 → #1140 → 本 PR → #1163。
结论
执行接入设计正确(JIT 失败回退 rbpf),BPF_END 条件为系列中唯一正确者;唯一阻塞是 perf/bpf.rs 与 dev 冲突。请 rebase 解决冲突,并顺带统一 #1140/#1142 的 BPF_END 方向后重跑 CI。冲突解决前维持 request changes。
|
Closing in favor of rbpf PR #152 (qmonnet/rbpf#152). |
2 participants
问题
在 JIT 框架（#1142）和 x86_64 后端（#1140）基础上，添加 AArch64 eBPF JIT 后端，并将 JIT 编译接入 StarryOS BPF 执行路径（
EbpfExecutor），使 JIT 编译后的原生代码能被实际调用。同时修复 x86_64 的emit_stRCX 寄存器冲突。变更
jit_aarch64.rs：1102 行，完整实现 AArch64 JIT 后端，覆盖 ALU64/ALU32/JMP/MEM/CALL/BPF_END 指令perf/bpf.rs：EbpfExecutor枚举 +try_jit()+execute_program()分发，JIT 失败时自动回退到 rbpf 解释器jit_x86_64.rs：修复emit_st中base == X86_RCX时使用 X86_R11 作为 scratchReview 后修复
patch_u32添加buf.counting()检查，防止 sizing pass 中空指针解引用#[cfg(any(target_arch = "aarch64", target_arch = "riscv64", target_arch = "x86_64"))]门控 + 不支持架构的 fallbacktry_jit_compile返回None，修复 loongarch64 构建失败bpf_insnre-export cfg gate 补x86_64，三架构风格一致(insn.code & BPF_X) == 0→!= 0，rbpf 约定BPF_X(0x08) 才表示 BE，BPF_K(0x00) 表示 LE；修复三个后端（aarch64/x86_64/riscv64）的 TO_BE/TO_LE 条件反转Logic
AArch64 寄存器映射：BPF R0-R5 → x0-x5（caller-saved）、R6-R9 → x19-x22（callee-saved）、R10 → x25 栈帧指针。帧布局：576 字节（512 BPF栈 + 64 callee-saved），16 字节对齐。除零保护：DIV 除零返回 0，MOD 除零保持 dst 不变。
EbpfExecutor优先尝试 JIT 编译，失败则用 rbpf 解释器执行，确保兼容性。Drop 顺序保证先释放 JIT buffer 再释放 BPF 程序。