1CSE 120CSE 120Principles of Operating Principles of Operating SystemsSystemsFall 2000Fall 2000Lecture 2: Architectural Support for Lecture 2: Architectural Support for Operating SystemsOperating SystemsGeoffrey M. VoelkerGeoffrey M. VoelkerSeptember 20, 2000 CSE 120 -- Lecture 2 –Arch Support 2Why Start With Architecture?Why Start With Architecture?l Operating system functionality fundamentally depends upon the architectural features of the computerl Architectural support can greatly simplify (or complicate) OS tasksu Early PC operating systems (DOS, MacOS) lacked virtual memory in part because the architecture did not support itu Early Sun 1 computers used two M68000 CPUs, which do not support VM, to implement it2September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 3Types of Arch SupportTypes of Arch Supportl Manipulating privileged machine stateu Protected instructionsu Manipulate device registers, TLB entries, etc.l Generating and handling “events”u Interrupts, exceptions, system calls, etc.u Respond to external eventsu CPU requires software intervention to handle fault or trapSeptember 20, 2000 CSE 120 -- Lecture 2 –Arch Support 4Protected InstructionsProtected Instructionsl A subset of instructions of every CPU is restricted to use by the OSu Known as protected (privileged) instructionsl Only the operating system can u Directly access I/O devices (disks, printers, etc.)» Security, fairness (why?)u Manipulate memory management state» Page table pointers, page protection, TLB management, etc.u Manipulate protected control registers » Kernel mode, interrupt levelu Halt instruction (why?)3September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 5OS ProtectionOS Protectionl How do we know if we can execute a protected instruction?u 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)u Mode is indicated by a status bit in a protected control registeru User programs execute in user modeu OS executes in kernel mode (OS == “kernel”)l Protected instructions only execute in kernel modeu The CPU checks mode bit when protected instr. executesu Setting mode bit must be a protected instructionSeptember 20, 2000 CSE 120 -- Lecture 2 –Arch Support 6Memory ProtectionMemory Protectionl OS must be able to protect programs from each otherl OS must protect itself from user programsl May or may not protect user programs from OSl Memory management hardware provides memory protection mechanismsu Base and limit registersu Page table pointers, page protection, TLBu Virtual memoryu Segmentationl Manipulation of memory management hardware are protected (privileged) operations4September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 7EventsEventsl An event is an “unnatural” change in control flowu Events immediately stop current executionu Changes mode or context (machine state) or bothl The kernel defines a handler for each event typeu Event handlers always execute in kernel modeu The specific types of events are defined by the machinel Once the system is booted, all entry to the kernel occurs as the result of an eventu In effect, the operating system is one big event handlerSeptember 20, 2000 CSE 120 -- Lecture 2 –Arch Support 8Categorizing EventsCategorizing Eventsl Two kinds of events, interrupts and exceptionsl Exceptions are caused by executing instructionsu CPU requires software intervention to handle a fault or trapl Interrupts are caused by an external eventu Device finishes I/O, timer expires, etc.u S/I – also async system trap (AST), async or deferred procedure call (APC or DPC)u Terms may be used slightly differently by various OS, CPUssoftware interruptinterruptInterrupts (async)syscall trapfaultExceptions (sync)DeliberateUnexpected5September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 9FaultsFaultsl Hardware detects and reports “exceptional” conditionsu Page fault, unaligned access, divide by zerol Upon exception, hardware faultsu Must save state (PC, regs, mode, etc.) so that the faulting process can be restartedl Modern OSes use VM faults for many functionsu Debugging, distributed VM, GC, copy-on-writel Fault exceptions are a performance optimizationu Could detect faults by inserting extra instructions into code (at a significant performance penalty)September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 10Handling FaultsHandling Faultsl Some faults are handled by “fixing” the exceptional condition and returning to the faulting contextu Page faults cause the OS to place the missing page into memoryu Fault handler resets PC of faulting context to re-execute instruction that caused the page faultl Some faults are handled by notifying the processu Fault handler munges the saved context to transfer control to a user-mode handler on return from faultu Handler must be registered with OSu Unix signals or NT user-mode Async Procedure Calls (APCs)» SIGHUP, SIGTERM, SIGSEGV, etc.6September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 11Handling Faults (2)Handling Faults (2)l The kernel may handle unrecoverable faults by killing the user processu Program fault with no registered handleru Halt process, write process state to file, destroy processu 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 instructionu These faults considered fatal, operating system crashesu Unix panic, Windows “Blue screen of death”September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 12System CallsSystem Callsl For a user program to do something “privileged” (e.g., I/O) it must call an OS procedureu Known as crossing the protection boundary, or a protected procedure calll Arch provides a system call instruction that:u Causes an exception, which vectors to a kernel handleru Passes a parameter determining the system routine to callu Saves caller state (PC, regs, mode) so it can be restoredu Returning from system call restores statel Arch must permit OS to:u Verify input parameters (e.g., valid addresses for buffers)u Restore saved state, return to user mode, resume execution7September 20, 2000 CSE 120 -- Lecture 2 –Arch Support 13System CallSystem CallKernel modeNetscape: read()User moderead() kernel routineTrap to kernel mode, save stateTrap handlerFind read handler in vector tableRestore state, return to user level, resume
View Full Document
Unlocking...