docs(zhihu): add part9 — multi-pCPU deep dive#8
Conversation
New deep-dive article picking up the multi_pcpu thread part8's ending teased. Covers: real PSCI CPU_ON via smc #0 from EL2, per-pCPU stacks, TPIDR_EL2 banked context pointer, inject_spi() reading physical GICD_IROUTER to dodge the DEVICES SpinLock deadlock, cross-pCPU wake via icc_sgi1r_el1 SGI 0, WFI passthrough, ensure_vtimer_enabled re-arming physical GICR each entry, multi_pcpu vs multi_vm feature mutex. ~340 lines. Code claims independently verified by Codex against the actual source (src/main.rs, src/global.rs, src/guest_loader.rs, arch/aarch64/boot.S, arch/aarch64/exception.S) — all 7 technical points accurate. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two fixes from Codex review: - MUST-FIX: '四个非平凡的问题' said 4 but body has 7. Change to 七个 + expand the intro to preview three representative subjects. - MINOR: 'EL2 绕过 Stage-2' could be misread as 'bypasses all translation'. Add qualifier that EL2's own Stage-1 + memory attributes still apply; only Stage-2 is transparent to EL2. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8f4fc14ea7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 几个值得点出的细节: | ||
|
|
||
| - **`smc #0` 从 EL2 直接进 EL3**——`HCR_EL2.TSC` 只拦 EL1 的 SMC,EL2 自己发出去的 SMC 是直通的。 | ||
| - **PSCI CPU_ON 的 function ID 是 `0xC400_0003`**(SMC64 调用约定,bit[31] 表示 fast call,bit[30] 表示 SMC64,bit[29:24]=0x84 是 PSCI service)。 |
There was a problem hiding this comment.
Correct the SMCCC owner field for CPU_ON
When readers use this paragraph to derive PSCI function IDs, the bit breakdown is wrong: in 0xC4000003, bits[29:24] are 0x04 (the Standard Secure Service/PSCI owner range), while 0x84 includes the fast-call bit from the SMC32-style prefix and cannot fit in a 6-bit owner field. This makes the article teach an invalid SMCCC encoding even though the constant itself is correct.
Useful? React with 👍 / 👎.
| hcr &= !HCR_TWI; | ||
| unsafe { asm!("msr hcr_el2, {}", "isb", in(reg) hcr, ...) } | ||
|
|
||
| // 4. 清 CPTR_EL2 的 trap 位(否则任何 FP/SIMD/SVE/SME 都陷到 EL3) |
There was a problem hiding this comment.
Fix the CPTR_EL2 trap destination
In the secondary-EL2 setup explanation, this says clearing CPTR_EL2 prevents FP/SIMD/SVE/SME from trapping to EL3, but those trap controls route lower-EL accesses to EL2; EL2's own SIMD trapping to EL3 is controlled by CPTR_EL3 (the Part 7 issue). As written, this conflates two different control registers and misexplains why the secondary init step matters.
Useful? React with 👍 / 👎.
What
New 知乎 article ~340 lines picking up the `multi_pcpu` thread part8's ending teased. Covers seven non-trivial problems:
Plus a feature-mutex discussion (`multi_pcpu` vs `multi_vm`) and a teaser for the next article (FF-A cross-world memory sharing).
Review trail
Ready to publish on 知乎 after merge.
🤖 Generated with Claude Code