1. CS 153 Design of Operating Systems Spring 2015 Lecture 3: Intro and Architectural Support for Operating Systems

2. Administrivia l Email your respective TA about project group u You need to have sent us email before class next Friday l Office hours on the course webpage (link @ Piazza) u Instructor: Tue 4 – 5PM, Fri 4:15 – 5:15PM WCH 334 u TA: Mon 2 - 3pm WCH110, or by email appointment »TA much more experienced with the projects l Project 1 out! 2

3. Categorizing Events l Two kinds of events: synchronous and asynchronous l Sync events are caused by executing instructions u Example? l Async events are caused by an external event u Example? CPU ticks Synchronous events Asynchronous events 3

4. 4 Categorizing Events l Two kinds of events: synchronous and asynchronous u Sync events are caused by executing instructions u Async events are caused by an external event l Two reasons for events: unexpected and deliberate l Unexpected events are, well, unexpected u Example? l Deliberate events are scheduled by OS or application u Why would this be useful?

5. 5 Categorizing Events l This gives us a convenient table: u Terms may be used slightly differently by various OSes, CPU architectures… u Will cover faults, system calls, and interrupts next UnexpectedDeliberate Synchronousfaultsoftware interrupt (syscall trap) AsynchronousinterruptAsynchronous system trap (AST)

6. 6 Faults l Hardware detects and reports “exceptional” conditions u Page fault, unaligned access, divide by zero l Upon exception, hardware “faults” (verb) u Must save state (PC, regs, mode, etc.) so that the faulting process can be restarted

7. 7 Handling Faults l Some faults are handled by “fixing” the exceptional condition and returning to the faulting context u Page faults cause the OS to place the missing page into memory u Fault handler resets PC of faulting context to re-execute instruction that caused the page fault l Some faults are handled by notifying the process u Fault handler changes the saved context to transfer control to a user-mode handler on return from fault u Handler must be registered with OS u Unix signals or NT user-mode Async Procedure Calls (APCs) »SIGFPE, SIGALRM, SIGHUP, SIGTERM, SIGSEGV, etc.

8. 8 Handling Faults l The kernel may handle unrecoverable faults by killing the user process (core dump) u Program fault with no registered handler u Halt process, write process state to file, destroy process u In Unix, the default action for many signals (e.g., SIGSEGV) l What about faults in the kernel? u Dereference NULL, divide by zero, undefined instruction u These faults considered fatal, operating system crashes u Unix panic, Windows “Blue screen of death” »Kernel is halted, state dumped to a core file, machine locked up u Improvement from Windows 95 to Windows 7 »Where does the improvement come from?

9. 9 Categorizing Events UnexpectedDeliberate Synchronousfaultsoftware interrupt (syscall trap) AsynchronousinterruptAsynchronous system trap (AST)

10. 10 System Calls l For a user program to do something “privileged” (e.g., I/O) it must call an OS procedure u Known as crossing the protection boundary, or a protected procedure call l Hardware provides a system call instruction that: u Causes an exception, which invokes a kernel handler u Passes a parameter determining the system routine to call u Saves caller state (PC, regs, mode) so it can be restored »Why save mode? u Returning from system call restores this state

11. 11 System Call Kernel mode emacs: read() User mode read() kernel routine Trap to kernel mode int 0x80 / sysenter Trap handler: Find read handler Restore state, return to user level, resume execution save state Who saves PC?

12. CPU Modes/Privileges l System call u Ring 3  Ring 0 12

13. Another view 13 Kernel Stack 0x00000000 0xFFFFFFFF Kernel Code Address Space SP2 PC1 User Stack User Code PC2 SP1

14. 14 System Call Questions l There are hundreds of syscalls. How do we let the kernel know which one we intend to invoke? u Before issuing int $0x80 or sysenter, set %eax with the syscall number l System calls are like function calls, but how to pass parameters? u Just like calling convention in syscalls, typically passed through %ebx, %ecx, %edx, %esi, %edi, %ebp l How to reference kernel objects (e.g., files, sockets)? u Naming problem – an integer mapped to a unique object »int fd = open(“file”); read(fd, buffer); u Why can’t we reference the kernel objects by memory address?

15. 15 System Call Questions l What if the kernel executes a system call? l How to reference kernel objects as arguments or results to/from system calls? u A naming issue u Use integer object handles or descriptors »E.g., Unix file descriptors »Only meaningful as parameters to other system calls u Also called capabilities (more later when we do protection) u Why not use kernel addresses to name kernel objects?

16. 16 Categorizing Events UnexpectedDeliberate Synchronousfaultsoftware interrupt (syscall trap) AsynchronousinterruptAsynchronous system trap (AST)

17. 17 Interrupts l Interrupts signal asynchronous events u I/O hardware interrupts u Software and hardware timers

18. 18 Interrupts l Interrupts signal asynchronous events u I/O hardware interrupts u Software and hardware timers l Two flavors of interrupts u Precise: CPU transfers control only on instruction boundaries u Imprecise: CPU transfers control in the middle of instruction execution »What does that mean? u OS designers like precise interrupts, CPU designers like imprecise interrupts »Why?

19. 19 Timer – special interrupt l The timer is critical for an operating system l It is the fallback mechanism by which the OS reclaims control over the machine u Timer is set to generate an interrupt after a period of time »Setting timer is a privileged instruction u Basis for scheduling multiple tasks (more later…) u When timer expires, generates an interrupt l Prevents infinite loops u OS can always regain control from erroneous or malicious programs that try to hog CPU l Also used for time-based functions (e.g., sleep())

20. 20 Timer l How does it work? u Mechanical resonance of a vibrating crystal that is integrated into an electronic oscillator circuit

21. 21 I/O Control l I/O issues u Initiating an I/O u Completing an I/O l Initiating an I/O u Special instructions u Memory-mapped I/O »Device registers mapped into address space »Writing to address sends data to I/O device

22. 22 I/O using Interrupts l Interrupts are the basis for asynchronous I/O u OS initiates I/O u Device operates independently of rest of machine u Device sends an interrupt signal to CPU when done u OS maintains a vector table containing a list of addresses of kernel routines to handle various events u CPU looks up kernel address indexed by interrupt number, context switches to routine CPU read() begins Disk read() ends interrupt I/O initiation

23. User Mode Ring 3 Interrupt Illustrated 23 Device Save user process’s state Execute device driver Restore state Restore state User process User process Resume process Raise Interrupt Suspend user process Execute OS’s interrupt handler Clear interrupt Return to Ring 3 Kernel Mode Ring 0

24. 24 I/O Example 1. Ethernet receives packet, writes packet into memory 2. Ethernet signals an interrupt 3. CPU stops current operation, switches to kernel mode, saves machine state (PC, mode, etc.) on kernel stack 4. CPU reads address from vector table indexed by interrupt number, branches to address (Ethernet device driver) 5. Ethernet device driver processes packet (reads device registers to find packet in memory) 6. Upon completion, restores saved state from stack

25. 25 Interrupt Questions l Interrupts halt the execution of a process and transfer control (execution) to the operating system u Can the OS be interrupted? (Consider why there might be different interrupt levels) u Why not transfer control to user mode? l Interrupts are used by devices to have the OS do stuff u What is an alternative approach to using interrupts? u What are the drawbacks of that approach?

26. 26 Synchronization l Interrupts cause difficult problems u An interrupt can occur at any time u A handler can execute that interferes with code that was interrupted l Need to guarantee that short instruction sequences execute atomically u Disable interrupts – turn off interrupts before sequence, execute sequence, turn interrupts back on u void driver_setup (void) { DISABLE_INTERRUPTS() global_variable += 100; assert( global_variable == 200); ENABLE_INTERRUPTS() }

27. 27 Synchronization l OS must be able to synchronize concurrent execution l Need to guarantee that short instruction sequences execute atomically u Special atomic instructions – read/modify/write a memory address, test and conditionally set a bit based upon previous value »XCHG on x86

28. 28 Summary l Faults u Handled by the OS immediately l System calls u Used by user-level processes to access OS functions u Access what is “in” the OS l Exceptions u Unexpected event during execution (e.g., divide by zero) l Interrupts u Timer, I/O

29. 29 Next Time… l Processes u Read Chapter 3