1CSE 120CSE 120Principles of Operating Principles of Operating SystemsSystemsFall 2002Fall 2002Lecture 3: Architectural Support for Lecture 3: Architectural Support for Operating SystemsOperating SystemsGeoffrey M. VoelkerGeoffrey M. VoelkerSeptember 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 2Why Start With Architecture?Why Start With Architecture?z Operating system functionality fundamentally depends upon the architectural features of the computerz 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)2September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 3Architectural Features for OSArchitectural Features for OSz Features that directly support the OS include◆ Protection (kernel/user mode)◆ Protected instructions◆ Memory protection◆ System calls◆ Interrupts and exceptions◆ Timer (clock)◆ I/O control and operation◆ Synchronization (atomic instructions)September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 4Types of Arch SupportTypes of Arch Supportz Manipulating privileged machine state◆ Protected instructions◆ Manipulate device registers, TLB entries, etc.z Generating and handling “events”◆ Interrupts, exceptions, system calls, etc.◆ Respond to external events◆ CPU requires software intervention to handle fault or trap3September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 5Protected InstructionsProtected Instructionsz A subset of instructions of every CPU is restricted to use only by the OS◆ Known as protected (privileged) instructionsz Only the operating system can ◆ Directly access I/O devices (disks, printers, etc.)» Security, fairness (why?)◆ Manipulate memory management state» Page table pointers, page protection, TLB management, etc.◆ Manipulate protected control registers » Kernel mode, interrupt level◆ Halt instruction (why?)September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 6OS ProtectionOS Protectionz 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”)z Protected instructions only execute in kernel mode◆ The CPU checks mode bit when protected instr. executes◆ Setting mode bit must be a protected instruction4September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 7Memory ProtectionMemory Protectionz OS must be able to protect programs from each otherz OS must protect itself from user programsz May or may not protect user programs from OSz Memory management hardware provides memory protection mechanisms◆ Base and limit registers◆ Page table pointers, page protection, TLB◆ Virtual memory◆ Segmentationz Manipulating memory management hardware uses protected (privileged) operationsSeptember 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 8EventsEventsz An event is an “unnatural” change in control flow◆ Events immediately stop current execution◆ Changes mode, context (machine state), or bothz The kernel defines a handler for each event type◆ Event handlers always execute in kernel mode◆ The specific types of events are defined by the machinez 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 handler5September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 9Categorizing EventsCategorizing Eventsz Two kinds of events, interrupts and exceptionsz Exceptions are caused by executing instructions◆ CPU requires software intervention to handle a fault or trapz Interrupts are caused by an external event◆ Device finishes I/O, timer expires, etc.z Two reasons for events, unexpected and deliberatez Unexpected events are, well, unexpected◆ What is an example?z Deliberate events are scheduled by OS or application◆ Why would this be useful?September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 10Categorizing Events (2)Categorizing Events (2)z This gives us a convenient table:◆ Terms may be used slightly differently by various OSes, CPU architectures…◆ Software interrupt – a.k.a. async system trap (AST), async or deferred procedure call (APC or DPC)z Will cover faults, system calls, and interrupts next◆ Does anyone remember from CSE 141 what a software interrupt is?software interruptinterruptInterrupts (async)syscall trapfaultExceptions (sync)DeliberateUnexpected6September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 11FaultsFaultsz Hardware detects and reports “exceptional” conditions◆ Page fault, unaligned access, divide by zeroz Upon exception, hardware “faults” (verb)◆ Must save state (PC, regs, mode, etc.) so that the faulting process can be restartedz Modern OSes use VM faults for many functions◆ Debugging, distributed VM, GC, copy-on-writez Fault exceptions are a performance optimization◆ Could detect faults by inserting extra instructions into code (at a significant performance penalty)September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 12Handling FaultsHandling Faultsz 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 faultz Some faults are handled by notifying the process◆ Fault handler chnages 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.7September 30, 2002 CSE 120 – Lecture 3 – Architectural Support for OSes 13Handling Faults (2)Handling Faults (2)z The kernel may handle unrecoverable faults by killing the user process◆ Program fault with no registered
View Full Document