Lecture 2:Lecture 2:Architectural Support for Architectural Support for OSesOSesCSE 120: Principles of Operating SystemsAlex C. SnoerenHW 1 Due Tuesday 10/03CSE 120 – Lecture 2: Architectural Support for OSes 2Why Architecture?Why Architecture? Operating systems mediate between applications and thephysical hardware of the computer◆ Key goals of an OS are to enforce protection and resource sharing◆ If done well, applications can be oblivious to HW details◆ Unfortunately for us, the OS is left holding the bag The details of the HW architecture matter◆ Small differences in hardware may have large repercussions◆ Early PC operating systems did not support virtual memory, due inlarge part to the fact that the H/W provided no support◆ Sun 1 machines used an entirely separate processor just to managevirtual memory! (M68000 chips did not have hardware support forvirtual memory.)CSE 120 – Lecture 2: Architectural Support for OSes 3Types of Arch SupportTypes of Arch Support Providing protected machine state◆ Device registers, memory management state, etc.◆ Manipulated with privileged instructions◆ Allows OS to enforce protection Generating and handing asynchronous signals◆ Method to respond to external events◆ Interrupts, exceptions, system calls, etc.◆ Allows OS to enforce sharing Mechanisms to handle concurrency◆ More on this in a few lectures…CSE 120 – Lecture 2: Architectural Support for OSes 4Architectural FeaturesArchitectural Features Privileged instructions Protection modes (user/kernel) Memory protection mechanisms Interrupts and exceptions Timer (clock) I/O control and operation System calls Synchronization primitives (e.g., atomic instructions)CSE 120 – Lecture 2: Architectural Support for OSes 5Privileged InstructionsPrivileged Instructions A select few CPU instructions available only to OS◆ Allows access to protected state◆ Perform global operations For example, only the OS should be able to:◆ Directly access I/O devices (disks, printers, etc.)» Allows OS to enforce security and fairness◆ Manipulate memory management state» E.g., page tables, protection bits, TLB entries, etc.◆ Adjusted protected control registers» Change between user/kernel mode or raise/lower interrupt level◆ Execute the halt instructionCSE 120 – Lecture 2: Architectural Support for OSes 6OS ProtectionOS Protection How does CPU know when an instruction is OK?◆ Architecture must support (at least) two modes of operation:kernel and user mode» VAX, x86 support four modes (rings); early archs 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 a user mode◆ OS executes in kernel mode (OS == “kernel”) Protected instructions only execute in kernel mode◆ CPU checks mode bit when protected instruction executes◆ Setting mode bit must be a protected instruction◆ Attempts to execute in user mode are detected and preventedCSE 120 – Lecture 2: Architectural Support for OSes 7Memory ProtectionMemory Protection 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 protection◆ Base and limit registers◆ Segmentation◆ Page table pointers, page protection, TLB◆ Virtual memory Manipulating memory management hardware usesprotected (privileged) instructionsCSE 120 – Lecture 2: Architectural Support for OSes 8EventsEvents An event is an “unnatural” change in control flow◆ Events immediately stop current execution◆ Change mode, context (machine state), or both The kernel defines a hander for each event type◆ Event handlers always execute in kernel mode◆ The specific types of events are defined by the machine Events are the only entry into the kernel◆ System boot is the first event, loads OS◆ Once in user mode, only way back to kernel is an event The OS is really just one big event handlerCSE 120 – Lecture 2: Architectural Support for OSes 9Types of EventsTypes of Events Two kinds of events: exceptions and interrupts Exceptions are caused by executing instructions◆ Exceptions indicate software intervention is needed Interrupts are caused by external event◆ Usually hardware devices, timers, etc. Events can be both expected and unexpected◆ Unexpected, a.k.a. asynchronous events◆ Sometimes events are caused deliberatelyCSE 120 – Lecture 2: Architectural Support for OSes 10Types of EventsTypes of Events Each type has its own special term◆ Terms vary slightly across architectures, OSes…◆ Software interrupt is also known as async system trap (AST),async or deferred procedure call (A/DPC)Software interrupt(H/W) InterruptInterruptsSyscall trapFaultExceptionsDeliberateUnexpectedCSE 120 – Lecture 2: Architectural Support for OSes 11FaultsFaults Hardware detects and reports “exceptional” conditions◆ Page fault, unaligned memory access, divide by zero Upon detecting an exception, CPU “faults”◆ Needs to save context (PC, registers, mode bit, etc.) so thatfaulting instruction can be resumed OSes use page faults to implement many things◆ Debugging, garbage collection, copy-on-write, etc. Faults are strictly a performance optimization◆ Not needed for correctness◆ Extra code could be used to test for fault conditions, but atsignificant performance expenseCSE 120 – Lecture 2: Architectural Support for OSes 12Handling FaultsHandling Faults Some faults are silently fixed by the OS◆ Once exceptional condition is dealt with, process resumes» E.g., page faults cause the OS to load the missing page◆ Fault handler reloads the context of the faulting process andreissues the instruction that caused the fault Others are passed on to the application itself◆ OS fault handler modifies the saved context to transfer controlto a user-mode handler on return from fault◆ Applications must pre-register handlers with the OS◆ Unix signals or NT user-mode Async Procedure Calls (APCs)» SIGALRM, SIGHUP, SIGTERM, etc.CSE 120 – Lecture 2: Architectural Support for OSes 13Fatal FaultsFatal Faults Some faults cannot be properly handled◆ OS has no default handler for the particular fault◆ Application also failed to register a handler◆ App is halted, state dumped to a (core) file,
View Full Document
Unlocking...