aos lab 5: system calls
DESCRIPTION
TRANSCRIPT
Normal execution of a processor
While running a user process:
1 Read an instruction
2 Advance the program counter
3 Execute the instruction
4 Jump to 1
Normal execution of a processor
While running a user process:
1 Read an instruction
2 Advance the program counter
3 Execute the instruction
4 Jump to 1
Normal execution of a processor
While running a user process:
1 Read an instruction
2 Advance the program counter
3 Execute the instruction
4 Jump to 1
Normal execution of a processor
While running a user process:
1 Read an instruction
2 Advance the program counter
3 Execute the instruction
4 Jump to 1
Normal execution of a processor
While running a user process:
1 Read an instruction
2 Advance the program counter
3 Execute the instruction
4 Jump to 1
Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Extraordinary events
Events that break normal processor flow, to return control to thekernel:
1 A device signals that it needs attention (e.g. Timer): Interrupt
2 A user program does something illegal (e.g. divide by zero):Exception
3 A user program asks the kernel for a service: System call
Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Handling extraordinary events
The operating system must:
1 Save the processor’s registers for future resumption
2 Set up system for execution in the kernel
3 Choose a place for the kernel to start execution
4 Retrieve information about the event and call correspondinginterrupt handler
5 All the while, maintain isolation between user processes and thekernel
Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
Handling extraordinary events (2)
• Need hardware support
• On the x86, system calls generate an interrupt via the intinstruction
• The same mechanism for handling interrupts is used for handlingsystem calls and exceptions
• Traps are caused by the current running process• Interrupts are caused by devices
• Can happen concurrently
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
x86 protection
• 4 protection levels: 0 to 3• Privilege decreases in ascending order
• Most operating systems only use 2 levels: 0 (kernel mode) and 3(user mode)
• Interrupt handlers are defined in an interrupt descriptor table(idt) with a total of 256 entries
• int n generates a system call, where n is used to index theidt
• It is the job of the operating system to implement a handler foreach entry in the idt
int
• Fetches the nth descriptor from idt
• Ensures that the privilege level in the descriptor is 3
• As the interrupt is due to a user process, saves the process state(change in privilege level)
• Sets the instructor pointer to the required starting address in thedescriptor table and starts execution
• After execution, the OS calls iret to resume previous executionstate
int
• Fetches the nth descriptor from idt
• Ensures that the privilege level in the descriptor is 3
• As the interrupt is due to a user process, saves the process state(change in privilege level)
• Sets the instructor pointer to the required starting address in thedescriptor table and starts execution
• After execution, the OS calls iret to resume previous executionstate
int
• Fetches the nth descriptor from idt
• Ensures that the privilege level in the descriptor is 3
• As the interrupt is due to a user process, saves the process state(change in privilege level)
• Sets the instructor pointer to the required starting address in thedescriptor table and starts execution
• After execution, the OS calls iret to resume previous executionstate
int
• Fetches the nth descriptor from idt
• Ensures that the privilege level in the descriptor is 3
• As the interrupt is due to a user process, saves the process state(change in privilege level)
• Sets the instructor pointer to the required starting address in thedescriptor table and starts execution
• After execution, the OS calls iret to resume previous executionstate
int
• Fetches the nth descriptor from idt
• Ensures that the privilege level in the descriptor is 3
• As the interrupt is due to a user process, saves the process state(change in privilege level)
• Sets the instructor pointer to the required starting address in thedescriptor table and starts execution
• After execution, the OS calls iret to resume previous executionstate
The first system call
• Recall that initcode.S started off by invoking an execsystem call to load the init process (/init)
• Flow:1 Push the arguments and binary for exec on the process’s stack2 Put the system call number (SYS_exec) in %eax (obviously this
number should already be present in the system call table,*syscalls[])
3 Execute int T_SYSCALL
The first system call
• Recall that initcode.S started off by invoking an execsystem call to load the init process (/init)
• Flow:1 Push the arguments and binary for exec on the process’s stack2 Put the system call number (SYS_exec) in %eax (obviously this
number should already be present in the system call table,*syscalls[])
3 Execute int T_SYSCALL
The first system call
• Recall that initcode.S started off by invoking an execsystem call to load the init process (/init)
• Flow:1 Push the arguments and binary for exec on the process’s stack2 Put the system call number (SYS_exec) in %eax (obviously this
number should already be present in the system call table,*syscalls[])
3 Execute int T_SYSCALL
The first system call
• Recall that initcode.S started off by invoking an execsystem call to load the init process (/init)
• Flow:1 Push the arguments and binary for exec on the process’s stack2 Put the system call number (SYS_exec) in %eax (obviously this
number should already be present in the system call table,*syscalls[])
3 Execute int T_SYSCALL
The first system call
• Recall that initcode.S started off by invoking an execsystem call to load the init process (/init)
• Flow:1 Push the arguments and binary for exec on the process’s stack2 Put the system call number (SYS_exec) in %eax (obviously this
number should already be present in the system call table,*syscalls[])
3 Execute int T_SYSCALL
x86 traps
• 256 different interrupts• 0-31 software• 32-63 hardware• 64 system calls (T_SYSCALL)
x86 traps
• 256 different interrupts• 0-31 software• 32-63 hardware• 64 system calls (T_SYSCALL)
x86 traps
• 256 different interrupts• 0-31 software• 32-63 hardware• 64 system calls (T_SYSCALL)
x86 traps
• 256 different interrupts• 0-31 software• 32-63 hardware• 64 system calls (T_SYSCALL)
Setting up idt
• tvinit, called from main, sets up the entries in idt
• The address of the handler for each interrupt in idt is present invectors[], i.e. Interrupt i is handled by vectors[i]
• T_SYSCALL is handled specially: it is distinguished as a trapallowing multiple system calls to execute simultaneously
Setting up idt
• tvinit, called from main, sets up the entries in idt
• The address of the handler for each interrupt in idt is present invectors[], i.e. Interrupt i is handled by vectors[i]
• T_SYSCALL is handled specially: it is distinguished as a trapallowing multiple system calls to execute simultaneously
Setting up idt
• tvinit, called from main, sets up the entries in idt
• The address of the handler for each interrupt in idt is present invectors[], i.e. Interrupt i is handled by vectors[i]
• T_SYSCALL is handled specially: it is distinguished as a trapallowing multiple system calls to execute simultaneously
tvinit
1 void tvinit(void) {
2 int i;
3 for(i = 0; i < 256; i++)
4 SETGATE(idt[i], 0, SEG_KCODE <<3, vectors[i], 0);
5 SETGATE(idt[T_SYSCALL], 1, SEG_KCODE <<3,
6 vectors[T_SYSCALL], DPL_USER);
7 /∗ SETGATE(gate, istrap, sel, off, d)8 ∗ gate: idt entry9 ∗ istrap: 1 trap, 0 interrupt
10 ∗ sel: code segment11 ∗ off: offset within code segment12 ∗ d: privilege level ∗/13 initlock(&tickslock , "time");
14 }
Addresses of interrupt handlers
• xv6 uses a custom Perl script vectors.pl to generatevectors.S which holds entry points of interrupt handlers invectors[]
• Each entry point:1 Pushes an error code2 Pushes the interrupt number3 Jumps to alltraps
Addresses of interrupt handlers
• xv6 uses a custom Perl script vectors.pl to generatevectors.S which holds entry points of interrupt handlers invectors[]
• Each entry point:1 Pushes an error code2 Pushes the interrupt number3 Jumps to alltraps
Addresses of interrupt handlers
• xv6 uses a custom Perl script vectors.pl to generatevectors.S which holds entry points of interrupt handlers invectors[]
• Each entry point:1 Pushes an error code2 Pushes the interrupt number3 Jumps to alltraps
Addresses of interrupt handlers
• xv6 uses a custom Perl script vectors.pl to generatevectors.S which holds entry points of interrupt handlers invectors[]
• Each entry point:1 Pushes an error code2 Pushes the interrupt number3 Jumps to alltraps
alltraps
1 Pushes all processor registers into a struct trapframe• Once the call completes, the kernel can restore state from this
structure
2 Sets up the processor to run kernel C code (load SEG_KCPU,per-CPU data segment)
3 Calls the C trap handler trap
4 Once trap returns, alltraps restores structtrapframe and then calls iret to return control back to userspace
alltraps
1 Pushes all processor registers into a struct trapframe• Once the call completes, the kernel can restore state from this
structure
2 Sets up the processor to run kernel C code (load SEG_KCPU,per-CPU data segment)
3 Calls the C trap handler trap
4 Once trap returns, alltraps restores structtrapframe and then calls iret to return control back to userspace
alltraps
1 Pushes all processor registers into a struct trapframe• Once the call completes, the kernel can restore state from this
structure
2 Sets up the processor to run kernel C code (load SEG_KCPU,per-CPU data segment)
3 Calls the C trap handler trap
4 Once trap returns, alltraps restores structtrapframe and then calls iret to return control back to userspace
alltraps
1 Pushes all processor registers into a struct trapframe• Once the call completes, the kernel can restore state from this
structure
2 Sets up the processor to run kernel C code (load SEG_KCPU,per-CPU data segment)
3 Calls the C trap handler trap
4 Once trap returns, alltraps restores structtrapframe and then calls iret to return control back to userspace
alltraps
1 Pushes all processor registers into a struct trapframe• Once the call completes, the kernel can restore state from this
structure
2 Sets up the processor to run kernel C code (load SEG_KCPU,per-CPU data segment)
3 Calls the C trap handler trap
4 Once trap returns, alltraps restores structtrapframe and then calls iret to return control back to userspace
trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
trap
• Gets passed struct trapframe *tf
• Checks tf->trapno to decide if it was called for a system call(T_SYSCALL) or a hardware interrupt or an exception
• In case of:1 System call, it invokes syscall2 Hardware interrupt, it calls the hardware interrupt controller3 Exception, it prints the details and kills the user process
syscall
• Loads the system call number through proc->tf->eax
• Calls the corresponding system call from the syscalls table• Puts its return value in proc->tf->eax (available on return to
user space)• Conventionally negative numbers indicate errors while positive
ones indicate success
• System call arguments are retrieved using either argint,argptr, or argstr
syscall
• Loads the system call number through proc->tf->eax
• Calls the corresponding system call from the syscalls table• Puts its return value in proc->tf->eax (available on return to
user space)• Conventionally negative numbers indicate errors while positive
ones indicate success
• System call arguments are retrieved using either argint,argptr, or argstr
syscall
• Loads the system call number through proc->tf->eax
• Calls the corresponding system call from the syscalls table• Puts its return value in proc->tf->eax (available on return to
user space)• Conventionally negative numbers indicate errors while positive
ones indicate success
• System call arguments are retrieved using either argint,argptr, or argstr
syscall
• Loads the system call number through proc->tf->eax
• Calls the corresponding system call from the syscalls table• Puts its return value in proc->tf->eax (available on return to
user space)• Conventionally negative numbers indicate errors while positive
ones indicate success
• System call arguments are retrieved using either argint,argptr, or argstr
syscall
• Loads the system call number through proc->tf->eax
• Calls the corresponding system call from the syscalls table• Puts its return value in proc->tf->eax (available on return to
user space)• Conventionally negative numbers indicate errors while positive
ones indicate success
• System call arguments are retrieved using either argint,argptr, or argstr
Reading(s)
• Chapter 3, “Traps, interrupts, and drivers”, till section “Code:System calls" from “xv6: a simple, Unix-like teaching operatingsystem”