Skip to content

docs(zhihu): add part9 — multi-pCPU deep dive#8

Merged
willamhou merged 2 commits into
mainfrom
docs/zhihu-part9-multi-pcpu
Jun 8, 2026
Merged

docs(zhihu): add part9 — multi-pCPU deep dive#8
willamhou merged 2 commits into
mainfrom
docs/zhihu-part9-multi-pcpu

Conversation

@willamhou

Copy link
Copy Markdown
Owner

What

New 知乎 article ~340 lines picking up the `multi_pcpu` thread part8's ending teased. Covers seven non-trivial problems:

  1. QEMU virt secondary pCPU powered off at boot
  2. Real PSCI CPU_ON SMC (`0xC4000003`) from EL2 to QEMU EL3 firmware
  3. secondary EL2 state setup (VBAR/Stage-2/HCR_TWI/CPTR/GIC)
  4. `TPIDR_EL2` HW-banked per-pCPU context pointer
  5. Physical GICR re-arm every entry (guest writes only update shadow)
  6. `inject_spi()` deadlock on DEVICES SpinLock — fix by reading physical `GICD_IROUTER` directly
  7. Cross-pCPU wake via physical SGI 0 (`icc_sgi1r_el1`)

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

willamhou and others added 2 commits June 8, 2026 18:40
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>

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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)。

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@willamhou willamhou merged commit 9958fdc into main Jun 8, 2026
3 checks passed
@willamhou willamhou deleted the docs/zhihu-part9-multi-pcpu branch June 8, 2026 10:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant