kernel/swtch.S

The interface

swtch is called like a C function, with two pointers, old in a0 and new in a1 (calling convention). Its prototype is in kernel/defs.h. Both point at a struct context (kernel/proc.h:2): 14 eight-byte slots, ra, sp, then s0 to s11, at offsets 0, 8, 16, …, 104.

Export the label

.globl makes swtch visible to the linker, so C code in kernel/proc.c can call it. This file has no .section directive, so the code goes in the default .text section; the build places it at 0x800023e0 (kernel/kernel.asm).

Save the current thread's registers into old

Fourteen sd instructions store the current values into *old.

Why only these registers? Because swtch is an ordinary function call as far as the C compiler is concerned. The calling convention says a called function may destroy t0–t6 and a0–a7, so the compiler never keeps a value it still needs in them across a call; if it needs one later, it has already saved it on the stack, which stays intact. It also says a called function must preserve s0–s11 and sp, so the caller may keep live values in them. swtch saves exactly those, plus ra.

You can see this in the build: scheduler keeps the loop variable p in s1 across its call to swtch, and sched keeps its local intena in s3. Both values survive only because swtch saves and restores the s registers.

What is not saved, and why:

• The program counter: ra stands in for it. It holds the address right after the call swtch in the caller, which is exactly where this thread should resume.
• tp: it holds the hart ID, a property of the CPU, not of the thread. A process may stop on one CPU and resume on another; it must then see the new CPU’s ID, so tp must not travel with it.
• gp: the kernel does not use it.
• Floating-point registers: the kernel contains no floating-point instructions (the disassembly has none), so kernel threads never change them. Moreover, the FS field of mstatus is 0 (Off) at reset on QEMU and xv6 never sets it, so any floating-point instruction would trap anyway.
• The user registers: when the process trapped into the kernel, they were already saved in its trapframe, which stays in memory.
• CSRs such as satp and sstatus: all kernel threads share the kernel page table, and the interrupt state is handled by intena (see sched).

Load the new thread's registers from new

Fourteen ld instructions load ra, sp and s0–s11 from *new. The moment sp is loaded (line 26), the CPU is on the other thread’s stack: the scheduler’s stack (one of the boot stacks in stack0) or a process’s kernel stack.

Nothing is lost by loading over the old values, because they were all saved first. a0 and a1 are not touched, so new stays valid while it is read.

Return into the other thread

ret jumps to the address in ra, which now comes from new. There are two cases:

• The other thread was switched out earlier by its own call to swtch. Then ra is the instruction after that call (in sched or scheduler), and from that thread’s point of view swtch has simply returned, with its s registers and stack exactly as it left them.
• The other thread is a brand-new process that has never run. allocproc set its context.ra to forkret and its context.sp to the top of its empty kernel stack (kernel/proc.c:146), so ret “returns” into the start of forkret.