A3 第一次上 CPU：从 WFI 到 eret

A1 结束时，子进程 C 已经挂在 CPU2 的运行队列上，一个 IPI 正飞向还在 wfi 里睡觉的 CPU2。这一篇在 CPU2 上把镜头拉到最近：CPU 醒来、__schedule 选中 C、换页表、换寄存器、换栈，然后从 A1 伪造好的 ret_from_fork 一路走到 eret，最后让 C 在 EL0 看到 fork() 返回 0。这也是理解所有“任务切换”的最佳样本：新任务走的就是和老任务完全相同的切换代码。

0. 场景设定

1. 全景：15 步

2. ❶❷ 从 WFI 醒来

2.1 idle 在等什么

// kernel/sched/idle.c:271（简化）
static void do_idle(void)
{
        ...
        while (!need_resched()) {
                local_irq_disable();
                arch_cpu_idle_enter();
                if (cpu_idle_force_poll || tick_check_broadcast_expired())
                        cpu_idle_poll();
                else
                        cpuidle_idle_call();       // → cpuidle 驱动选一个 PSCI 状态，或 arch_cpu_idle()
                arch_cpu_idle_exit();
        }
        ...
        schedule_idle();                           // idle.c:375
}

没有 cpuidle 驱动时，最终会走到 arch/arm64/kernel/idle.c:23 的 cpu_do_idle()：dsb(sy); wfi;。进入 wfi 时中断是关着的（上面的 local_irq_disable()），这没有问题：ARM 架构规定，只要有未决的中断，即使它在 PSTATE 里被屏蔽，wfi 也会退出。退出之后，idle 代码重新打开中断，中断随即被处理。

2.2 IPI 做了什么：几乎什么都没做

// arch/arm64/kernel/smp.c:953
case IPI_RESCHEDULE:
        scheduler_ipi();       // include/linux/sched.h:1976 → preempt_fold_need_resched()
        break;

scheduler_ipi() 只做一件事：把 TIF_NEED_RESCHED “折叠”进 preempt_count。在 ARM64 上，preempt_count 的高 32 位存放的是取反的 need_resched 标志，0 表示需要调度（arch/arm64/include/asm/preempt.h）。折叠之后，preempt_count 的 64 位整体值就能反映“要不要调度”。真正的调度并不在 IPI 处理函数里做，而是在 IPI 返回、do_idle 重新检查 need_resched() 时发生。

IPI 只负责“叫醒”，不负责“调度”。 这是一个很重要的设计：中断处理函数运行在中断上下文里，不能直接切换任务；它只留下一个标记，让被打断的代码在合适的地方自己去调度。

3. ❸❹❺ __schedule(SM_IDLE)：选中 C

schedule_idle()（kernel/sched/core.c:6837）直接调用 __schedule(SM_IDLE)，不经过 sched_submit_work，因为 idle 任务没有要提交的块设备 IO 请求，也不是 workqueue worker。

// kernel/sched/core.c:6613（节选）
local_irq_disable();
rcu_note_context_switch(preempt);
rq_lock(rq, &rf);
smp_mb__after_spinlock();                           // ❸
update_rq_clock(rq);
prev_state = READ_ONCE(prev->__state);              // idle 永远是 TASK_RUNNING
if (sched_mode == SM_IDLE) {
        if (!rq->nr_running && !scx_enabled()) {    // 队列为空：直接 next = prev，不做任何事
                next = prev;
                goto picked;
        }
}
next = pick_next_task(rq, prev, &rf);               // ❹ nr_running = 1 → 选
picked:
clear_tsk_need_resched(prev);
clear_preempt_need_resched();
if (likely(prev != next)) {
        rq->nr_switches++;
        RCU_INIT_POINTER(rq->curr, next);           // ❺
        ++*switch_count;
        trace_sched_switch(preempt, prev, next, prev_state);
        rq = context_switch(rq, prev, next, &rf);
}

3.1 SM_IDLE 优化了什么

SM_IDLE 是 6.12 新加的模式（commit 3dcac251b066，v6.12-rc1）。idle 被“假唤醒”时，比如 IPI 实际上是给别的用途，或者任务刚被别的 CPU 偷走，队列可能是空的。这时直接 next = prev，跳过整个 pick_next_task，其中包括 newidle balance，也就是主动去别的 CPU 拉任务的那一步。在我们的场景里 nr_running = 1，所以不走这个捷径。

3.2 pick_next_task 的快路径

__pick_next_task（kernel/sched/core.c:5976）的快路径条件，在这里两条都满足：

• prev（idle）的调度类不高于 fair，因为 idle 类排在最后；
• rq->nr_running == rq->cfs.h_nr_queued，即 1 == 1，队列里全是 fair 任务。

于是直接调用 pick_next_task_fair(rq, prev, rf)：

pick_next_task_fair
 ├─ pick_task_fair → pick_eevdf(cfs_rq)
 │     └─ cfs_rq->nr_running == 1 → 直接返回唯一的 se（C），不做 eligible 判断（fair.c:937）
 ├─ prev->sched_class != fair → goto simple
 └─ put_prev_set_next_task(rq, idle, C)          （kernel/sched/sched.h:2488）
       ├─ put_prev_task_idle(rq, idle)
       └─ set_next_task_fair(rq, C, true) → set_next_entity(cfs_rq, &C->se)
             ├─ set_protect_slice(se)：se->vlag = se->deadline   ← A1 例 b 里保护 P 的机制，现在轮到保护 C
             ├─ cfs_rq->curr = se
             └─ se->prev_sum_exec_runtime = se->sum_exec_runtime (= 0)

3.3 rq->curr = C：切换还没发生，“当前任务”就已经变了

❺ 这一步之后，rq->curr 已经是 C，但 CPU2 实际上还在 idle 的栈上执行代码，要到 ❿ 才真正换过去。这段“名实不符”的窗口期对其他 CPU 来说是可见的，比如另一个 CPU 读 cpu_curr(2) 就会看到 C。所有依赖 rq->curr 的远程代码，都必须持有 rq 锁，或者能容忍这个窗口期。rq 锁要到 ⓬ 才释放。

源码注释还指出了一个 ARM64 特有的内存序要求：membarrier() 系统调用要求在写 rq->curr 之后、返回用户态之前，必须有一个全屏障。x86 等架构靠 switch_mm 里的写 CR3 或者 mmdrop 来提供这个屏障，而 ARM64 的 spin_unlock 只有 release 语义，所以这个屏障是由 ❾ __switch_to 里的 dsb(ish) 来提供的。

4. ❻❼❽ 换地址空间

4.1 四种组合

context_switch()（kernel/sched/core.c:5296）先按 prev/next 是否有用户地址空间，分四种情况处理 mm：

4.2 C 的第一个 ASID

ARM64 的 TLB 表项带有 ASID 标签，所以切换进程时不需要刷 TLB：只要换一个 ASID，旧进程的 TLB 表项就自动不会命中了。内核用 “代数（generation）+ ASID” 来管理有限的 ASID 空间。mm->context.id 的高位存代数，低位存 ASID 号。

A1 里 dup_mm → init_new_context 把 C 的 mm->context.id 设成了 0（arch/arm64/include/asm/mmu_context.h:174）。代数为 0 永远不等于当前代数，所以 C 的第一次切入一定走慢路径：

// arch/arm64/mm/context.c:215（节选）
asid = atomic64_read(&mm->context.id);                     // 0
old_active_asid = atomic64_read(this_cpu_ptr(&active_asids));
if (old_active_asid && asid_gen_match(asid) && ...)         // gen 不匹配 → 不走快路径
        goto switch_mm_fastpath;
raw_spin_lock_irqsave(&cpu_asid_lock, flags);
if (!asid_gen_match(asid)) {
        asid = new_context(mm);                             // 分配：例如 #42
        atomic64_set(&mm->context.id, asid);
}
if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending))
        local_flush_tlb_all();                              // 只有发生过 rollover 才会进来
atomic64_set(this_cpu_ptr(&active_asids), asid);
raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
switch_mm_fastpath:
arm64_apply_bp_hardening();
if (!system_uses_ttbr0_pan())
        cpu_switch_mm(mm->pgd, mm);                         // → cpu_do_switch_mm

cpu_do_switch_mm（arch/arm64/mm/context.c:349）里有一个很容易想反的细节：ASID 写在 TTBR1_EL1 里，而不是 TTBR0_EL1。Linux 设置了 TCR_EL1.A1 = 1，让 ASID 从 TTBR1 中取。这样在 SW PAN 模式下，可以随时把 TTBR0 换成指向空页表，禁止内核访问用户内存，而 ASID 保持不变。写入的顺序是：先把 TTBR0 设成保留值，再写 TTBR1（新 ASID），然后写 TTBR0（新页表），最后执行 isb。这个顺序保证了任何时刻都不会出现“新 ASID 配旧页表”的组合。

4.3 ❽ idle 借来的 mm 什么时候还

if (!prev->mm) {                        // idle 是内核线程
        rq->prev_mm = prev->active_mm;  // 记下借来的 X->mm
        prev->active_mm = NULL;
}

这里不能直接调用 mmdrop，因为此时还持有 rq 锁、中断也是关的，而 mmdrop 有可能触发整个 mm 的释放（如果 X 已经退出了），那是一个很重的操作。所以先记在 rq->prev_mm 里，到 ⓬ finish_task_switch 释放 rq 锁之后，再调用 mmdrop_lazy_tlb_sched。

5. ❾ __switch_to：ARM64 线程私有状态

arch/arm64/kernel/process.c:577。每一项都对应一块只属于“当前线程”的硬件状态：

6. ❿ cpu_switch_to：真正的切换只有 20 条指令

// arch/arm64/kernel/entry.S:825
SYM_FUNC_START(cpu_switch_to)
        save_and_disable_daif x11
        mov     x10, #THREAD_CPU_CONTEXT
        add     x8, x0, x10              // x8 = &idle->thread.cpu_context
        mov     x9, sp
        stp     x19, x20, [x8], #16      // 保存 idle 的 callee-saved 寄存器
        stp     x21, x22, [x8], #16
        stp     x23, x24, [x8], #16
        stp     x25, x26, [x8], #16
        stp     x27, x28, [x8], #16
        stp     x29, x9, [x8], #16       // fp, sp
        str     lr, [x8]                 // pc ← 返回地址（__switch_to 里 cpu_switch_to 之后那一行）
        add     x8, x1, x10              // x8 = &C->thread.cpu_context
        ldp     x19, x20, [x8], #16      // 恢复 C 的：x19 = 0, x20 = 0（copy_thread 写的）
        ...
        ldp     x29, x9, [x8], #16       // fp = &pt_regs->stackframe, x9 = &pt_regs
        ldr     lr, [x8]                 // lr = ret_from_fork
        mov     sp, x9                   // ★ 换栈：此后 sp 指向 C 的内核栈
        msr     sp_el0, x1               // ★ 换 current：get_current() 从此返回 C
        ptrauth_keys_install_kernel x1, x8, x9, x10
        scs_save x0
        scs_load_current
        restore_irq x11
        ret                              // ★ 跳到 lr = ret_from_fork

为什么只存 13 个寄存器？ 三个原因叠加在一起：

1. cpu_switch_to 是一次普通的函数调用。按照 AAPCS64 调用约定，x0-x18 是 caller-saved 寄存器，调用方的编译器在调用点已经假定它们会被破坏，所以不需要保存。
2. 用户态的全部寄存器，早在进入内核时就被 kernel_entry 保存到内核栈顶的 pt_regs 里了。栈一换，pt_regs 也就跟着换了。
3. FP/SIMD 走懒切换（第 5 节）。

x0 为什么贯穿全程不变？ 因为它就是返回值 last。ret 跳到 ret_from_fork 之后，x0 仍然是 idle 的 task_struct 指针，恰好作为 schedule_tail(prev) 的参数。对于老任务，比如之后 C 被切走、再被切回来时，cpu_switch_to 的 ret 回到 __switch_to，x0 就成了 __switch_to 的返回值 last，再赋给 context_switch 里的 prev。这就是 switch_to(prev, next, last) 里第三个参数的由来：切回来的时候，栈上保存的局部变量 prev 已经过时了，真正的“上一个任务”只能从寄存器里带过来。

sp_el0 为什么能存 current？ ARM64 在 EL1 运行内核时使用 SP_EL1 作为栈指针，SP_EL0 这个寄存器就空出来了。Linux 拿它来存当前任务的 task_struct 指针，这样 get_current() 只需要一条 mrs x0, sp_el0，不用访问内存。msr sp_el0, x1 这一条指令就完成了“切换 current”。

7. ⓫⓬⓭ ret_from_fork 与收尾：锁跨任务交接

// arch/arm64/kernel/entry.S:858
SYM_CODE_START(ret_from_fork)
        bl      schedule_tail            // x0 = prev = idle
        cbz     x19, 1f                  // x19 == 0 → 用户进程
        mov     x0, x20
        blr     x19                      // 内核线程：执行 fn(fn_arg)
1:      get_current_task tsk
        mov     x0, sp
        bl      asm_exit_to_user_mode
        b       ret_to_user

// kernel/sched/core.c:5271
asmlinkage __visible void schedule_tail(struct task_struct *prev)
{
        finish_task_switch(prev);           // ⓬
        preempt_enable();                   // ⓭
        if (current->set_child_tid)
                put_user(task_pid_vnr(current), current->set_child_tid);   // A1 里 CLONE_CHILD_SETTID 的兑现
        calculate_sigpending();
}

finish_task_switch(idle)（kernel/sched/core.c:5177）现在运行在 C 的栈上，但它清理的是 idle：

8. ⓮⓯ 返回 EL0

8.1 exit_to_user_mode：返回用户态之前的“待办清单”

// arch/arm64/kernel/entry-common.c:130（节选）
static void do_notify_resume(struct pt_regs *regs, unsigned long thread_flags)
{
        do {
                local_irq_enable();
                if (thread_flags & _TIF_NEED_RESCHED)   schedule();          // 又要调度？先让出去
                if (thread_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) do_signal(regs);
                if (thread_flags & _TIF_NOTIFY_RESUME)  resume_user_mode_work(regs);
                if (thread_flags & _TIF_FOREIGN_FPSTATE) fpsimd_restore_current_state();   // ← C 走这里
                local_irq_disable();
                thread_flags = read_thread_flags();
        } while (thread_flags & _TIF_WORK_MASK);
}

C 带着 TIF_FOREIGN_FPSTATE（第 5 节设置的），所以会在这里装载 FP/SIMD 状态，也就是从父进程那里继承来的那一份。如果这时 TIF_NEED_RESCHED 也被置上了，比如 ctrl 恰好被唤醒到 CPU2，C 会先 schedule() 让出 CPU。C 第一次返回用户态之前就可能被抢占，那样的话 FP 装载就推迟到它下次返回用户态时再做。

8.2 kernel_exit 0 与 eret

arch/arm64/kernel/entry.S:335 的 kernel_exit 0 按这个顺序执行：

1. 从 pt_regs 取出 pc 和 pstate，放进 x21、x22。
2. msr sp_el0, x23：把用户栈指针写回 SP_EL0。从这一刻起，sp_el0 不再是 current。这就是 __switch_to 要更新 per-cpu __entry_task 的原因：下一次从 EL0 进入内核时，kernel_entry 从 __entry_task 里取回 current（entry.S:224）。
3. 安装用户态 PAC 的 IA 密钥，设置 MTE 的 GCR_EL1，应用 SSBD。
4. msr elr_el1, x21; msr spsr_el1, x22。
5. ldp x0, x1, … 一直到 x28, x29，从 pt_regs 恢复全部通用寄存器。x0 = 0，这是 A1 里 copy_thread 写进去的。
6. 如果开了 KPTI，先经过 tramp_exit 切到 trampoline 向量和用户页表；然后执行 eret。

eret 之后，CPU 回到 EL0，pc 等于 svc #0 的下一条指令，x0 = 0。在 glibc 看来，就是 clone 返回了 0，于是 fork() 返回 0，demo 进入 if (pid == 0) 分支，打印出 [child ] pid=1235 first ran on cpu=2。

9. 紧接着：第一次 COW 缺页

C 返回用户态之后执行的前几条指令，几乎一定会写栈，比如函数调用时压栈、写局部变量。A1 里 dup_mm 已经把这些页的 PTE 改成了只读，于是：

EL0 写栈 → Data Abort（权限错误）→ el0_da（entry-common.c:663）→ do_page_fault
       → handle_mm_fault → do_wp_page → wp_page_copy：分配新页、复制 4KB、改 PTE 为可写
       → 返回 EL0，重新执行那条写指令

实际上 7 节里的 put_user(set_child_tid) 更早，那是 C 的第一次写，只不过它发生在内核态，走的是内核的 uaccess 缺页路径。

10. PREEMPT_RT 视角：这一段是不可抢占的

从 ❸ rq_lock（关中断）到 ⓬ finish_lock_switch（开中断），CPU2 一直是关中断、关抢占的。在 PREEMPT_RT 内核里也一样，因为 rq->lock 是 raw spinlock，调度器核心属于 RT 明确保留下来的“不可抢占区”（C3）。

所以这一段的长度会直接计入所有 RT 任务的最坏调度延迟。影响它的因素主要有：

11. 动手实验

11.1 用 function_graph 看完整路径

# 只跟踪 schedule_tail，也就是只有新任务第一次运行时才会走的路径
sudo trace-cmd record -p function_graph -g schedule_tail --max-graph-depth 3 ./demo 1
sudo trace-cmd report | head -40

期望看到类似下面的输出（示意）：

 2)               |  schedule_tail() {
 2)               |    finish_task_switch.isra.0() {
 2)   0.312 us    |      _raw_spin_unlock_irq();
 2)   0.905 us    |      mmdrop_lazy_tlb ...
 2)   2.107 us    |    }
 2)   0.420 us    |    __put_user_...  (set_child_tid)
 2)   3.260 us    |  }

2) 表示 CPU2，这和 A1 的选核结果对得上。

11.2 数一数“子进程的第一次切换”花了多久

sudo bpftrace -e '
tracepoint:sched:sched_wakeup_new { @t[args->pid] = nsecs; @cpu[args->pid] = args->target_cpu; }
tracepoint:sched:sched_switch /@t[args->next_pid]/ {
    printf("pid %d: wakeup_new -> first switch on cpu%d = %d us\n",
           args->next_pid, cpu, (nsecs - @t[args->next_pid]) / 1000);
    delete(@t[args->next_pid]);
}'

在 X9 上，目标 CPU 如果是 WFI 状态，这个值一般是个位数微秒；如果是簇掉电状态，会到上百微秒。可以用 echo 1 > /sys/devices/system/cpu/cpu2/cpuidle/state2/disable 禁用深度 idle 状态，对比前后的差别。

11.3 看切换次数和 ASID

grep -E "nr_switches|nr_voluntary|nr_involuntary" /proc/$(pgrep -n demo)/sched
# ARM64 没有直接导出 ASID；可以用 perf 事件观察 TLB 行为（事件名取决于具体的核）：
perf stat -e dTLB-load-misses,iTLB-load-misses ./demo 1

12. 小结

13. 自测