Traps and Sytem calls
There are three kinds of event which cause the CPU to set aside ordinary execution of instructions and force a transfer of control to special code that handles the event. We use trap as a generic term for these situations
- Trap is transparent
Trap’s process
- Xv6 handles all traps in the kernel, which means traps are not delivered to user code
- Four stages Xv6 trap handling proceeds
- Three distinct cases:
Kernel code (assembler or C) that processes a trap is often called a handler; the first handler instructions are usually written in assembler (rather than C) and are sometimes called a vector.
RISC-V trap machinery
- some inportant registers
- The RISC-V hardware does the following for all trap types when it needs to force a trap
Note that CPU doesn’t switch to the kernel pgtbl, neither a stack in kernel, and doesn’t save any registers except the PC, which should be done by kernel software.
Traps from user space
A trap may occur while executing in user space if the user program makes a system call (ecall instruction), or does something illegal, or if a device interrupts.
- when a trap occurs, which code blocks shoud be executed
- Trampoline:
If the trap is a system call, usertrap calls syscall to handle it; if a device interrupt, devintr; otherwise it’s an exception, and the kernel kills the faulting process.
Traps from kernel space
- what should kernel do before handling the trap?
- when a trap occurs, what code blocks should be executed?
code
- usertrap()
- kerneltrap()
- usertrapret()
- uservec
- sret
- userret
- ecall