User stacks, kernel stacks and the boot-turned-scheduler stack, the four instructions that move sp between them, where interrupts push their frames, and the save areas that are not stacks.
1warm-upChoose one
Where does a hart’s scheduler stack come from?
kernel/main.c
9// start() jumps here in supervisor mode on all CPUs.
A process is returning to user mode. The hart has just executed line 111 of userret,
csrw satp, a0, and has not reached line 118 yet. What is its state?
Hart 0’s scheduler has just switched to init (pid 1) for the first time. The hart is at
the first instruction of forkret, before line 520. What is its state?
kernel/proc.c
510// A fork child's very first scheduling by scheduler()
A timer interrupt arrives while hart 2 is in its scheduler’s interrupt window (between
lines 441 and 442 of proc.c). Which stack does kerneltrap run on, and does it call
yield?
kernel/trap.c
134// interrupts and exceptions from kernel code go here via kernelvec,
TRAMPOLINE is 0x3ffffff000 and PGSIZE is 0x1000. What address is the top of
slot 4’s kernel stack, the value uservec loads into sp for the process in proc[4]?
Give it in hex.
kernel/memlayout.h
46// map the trampoline page to the highest address,
Process A, running in user mode on hart 1, is interrupted by the timer. Hart 1 then runs
process B, which had been preempted the same way earlier. Put hart 1’s stacks in the
order sp visits them.
B’s user stack, loaded by ld sp, 48(a0) in userret
hart 1’s scheduler stack, loaded by ld sp, 8(a1) in swtch called from sched
A’s user stack
A’s kernel stack, loaded by ld sp, 8(a0) in uservec
B’s kernel stack, at the point inside sched where B stopped, loaded by swtch called from scheduler
20deepChoose one
kexit marks the process ZOMBIE and calls sched, never to return. What happens to
the kernel stack it was running on?
When process A gives up hart 1, why does sched switch to the scheduler stack
instead of picking process B and switching directly from A’s kernel stack to B’s?
True or false: while a process is running in user mode, its kernel stack still holds the
frames of its last system call.
Why?
24deepChoose all that apply
Hypothetically, hart 0’s scheduler stack overflows by 32 bytes: some code on it pushes
32 bytes below the bottom of hart 0’s slice of stack0 (0x80007890). Which of these
would be overwritten? (In this build kernel_pagetable is at 0x80007870, initproc at
0x80007878, ticks at 0x80007880, and cpus at 0x8000f9d0.)
25solidClick the line
In prepare_return, click the line that decides where sp will point when this process
next traps in from user mode.