6 3ULQFLSOHV RI 2SHUDWLQJ 6 VWHPV DOO Lecture 2 Architectural Support for Operating Systems Geoffrey M Voelker K 6WDUW LWK UFKLWHFWXUH Operating system functionality fundamentally depends upon the architectural features of the computer Architectural support can greatly simplify or complicate OS tasks Early PC operating systems DOS MacOS lacked virtual memory in part because the architecture did not support it Early Sun 1 computers used two M68000 CPUs to implement virtual memory M68000 did not have VM hardware support September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 2 1 7 SHV RI UFK 6XSSRUW Manipulating privileged machine state Protected instructions Manipulate device registers TLB entries etc Generating and handling events Interrupts exceptions system calls etc Respond to external events CPU requires software intervention to handle fault or trap September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 3 3URWHFWHG QVWUXFWLRQV A subset of instructions of every CPU is restricted to use only by the OS Known as protected privileged instructions Only the operating system can Directly access I O devices disks printers etc Security fairness why Manipulate memory management state Manipulate protected control registers Halt instruction why Page table pointers page protection TLB management etc Kernel mode interrupt level September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 4 2 26 3URWHFWLRQ How do we know if we can execute a protected instruction Architecture must support at least two modes of operation kernel mode and user mode VAX x86 support four modes earlier archs Multics even more Why Protect the OS from itself software engineering Mode is indicated by a status bit in a protected control register User programs execute in user mode OS executes in kernel mode OS kernel Protected instructions only execute in kernel mode The CPU checks mode bit when protected instr executes Setting mode bit must be a protected instruction September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 5 0HPRU 3URWHFWLRQ OS must be able to protect programs from each other OS must protect itself from user programs May or may not protect user programs from OS Memory management hardware provides memory protection mechanisms Base and limit registers Page table pointers page protection TLB Virtual memory Segmentation Manipulation of memory management hardware are protected privileged operations September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 6 3 YHQWV An event is an unnatural change in control flow The kernel defines a handler for each event type Events immediately stop current execution Changes mode context machine state or both Event handlers always execute in kernel mode The specific types of events are defined by the machine Once the system is booted all entry to the kernel occurs as the result of an event In effect the operating system is one big event handler September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 7 DWHJRUL LQJ YHQWV Two kinds of events interrupts and exceptions Exceptions are caused by executing instructions CPU requires software intervention to handle a fault or trap Interrupts are caused by an external event Device finishes I O timer expires etc Unexpected Deliberate Exceptions sync fault syscall trap Interrupts async interrupt software interrupt Software interrupt a k a async system trap AST async or deferred procedure call APC or DPC Terms may be used slightly differently by various OS CPUs September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 8 4 DXOWV Hardware detects and reports exceptional conditions Upon exception hardware faults verb Must save state PC regs mode etc so that the faulting process can be restarted Modern OSes use VM faults for many functions Page fault unaligned access divide by zero Debugging distributed VM GC copy on write Fault exceptions are a performance optimization Could detect faults by inserting extra instructions into code at a significant performance penalty September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 9 DQGOLQJ DXOWV Some faults are handled by fixing the exceptional condition and returning to the faulting context Page faults cause the OS to place the missing page into memory Fault handler resets PC of faulting context to re execute instruction that caused the page fault Some faults are handled by notifying the process Fault handler munges the saved context to transfer control to a user mode handler on return from fault Handler must be registered with OS Unix signals or NT user mode Async Procedure Calls APCs SIGALRM SIGHUP SIGTERM SIGSEGV etc September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 10 5 DQGOLQJ DXOWV The kernel may handle unrecoverable faults by killing the user process Program fault with no registered handler Halt process write process state to file destroy process In Unix the default action for many signals e g SIGSEGV What about faults in the kernel Dereference NULL divide by zero undefined instruction These faults considered fatal operating system crashes Unix panic Windows Blue screen of death September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 11 6 VWHP DOOV For a user program to do something privileged e g I O it must call an OS procedure Known as crossing the protection boundary or a protected procedure call Arch provides a system call instruction that Causes an exception which vectors to a kernel handler Passes a parameter determining the system routine to call Saves caller state PC regs mode so it can be restored Why save mode Returning from system call restores this state Arch must permit OS to Verify input parameters e g valid addresses for buffers Restore saved state reset mode resume execution September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 12 6 6 VWHP DOO Netscape read User mode Trap to kernel mode save state Kernel mode Trap handler Find read handler in vector table Restore state return to user level resume execution read kernel routine September 24 2001 CSE 120 Lecture 2 Architectural Support for OSes 13 6 VWHP DOO 4XHVWLRQV What would happen if kernel did not save state What if the kernel executes a system call What if a user program returns from a system call How to reference kernel objects as arguments or results to from system calls A naming issue Use integer object handles or descriptors Also called capabilities more later E g Unix file descriptors Why not
View Full Document
Unlocking...