Unformatted text preview:

1CSE 120CSE 120Principles of Operating Principles of Operating SystemsSystemsSystemsSystemsWinter 2007Winter 2007Lecture 2: Architectural Support for Lecture 2: Architectural Support for Operating SystemsOperating SystemsOperating SystemsOperating SystemsKeith Keith MarzulloMarzullo and Geoffrey M. and Geoffrey M. VoelkerVoelkerAdministriviaAdministriviaz Mailing listYou should be getting mail on the list If not let me knowYou should be getting mail on the list. If not, let me know.z Homework #1 Due 1/18z Project 0 Due 1/18 Done individually Project groupsJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 2zProject groups Send your group info to Jeremy and Michael ([email protected], [email protected])2Why Start With Architecture?Why Start With Architecture?z Operating system functionality fundamentally depends upon the architectural features of the computerupon the architectural features 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 bagz Architectural support can greatly simplify – or complicate – OS tasksJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 3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)Architectural Features for OSArchitectural Features for OSz Features that directly support the OS includeProtection (kernel/user mode)Protection (kernel/user mode) Protected instructions Memory protection System calls Interrupts and exceptions Timer (clock) I/O control and operationJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 4 Synchronization3Types of Arch SupportTypes of Arch Supportz Manipulating privileged machine stateProtected instructions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 trapzMechanisms to handle concurrencyJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 5zMechanisms to handle concurrency Interrupts, atomic instructionsProtected InstructionsProtected Instructionsz A subset of instructions of every CPU is restricted to use only by the OSuse 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.January 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 6 Manipulate protected control registers » Kernel mode, interrupt level Halt instruction (why?)4OS 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 modeOS executes in kernel mode (OS ==“kernel”)January 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 7OS executes in kernel mode (OS == kernel )z 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 preventedMemory ProtectionMemory Protectionz OS must be able to protect programs from each otherzOS must protect itself from user programszOS 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, TLBVi t lJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 8Virtual memory Segmentationz Manipulating memory management hardware uses protected (privileged) operations5EventsEventsz An event is an “unnatural” change in control flowEvents immediately stop current execution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 eventJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 9occurs as the result of an event In effect, the operating system is one big event handlerCategorizing EventsCategorizing Eventsz Two kinds of events, interrupts and exceptionszExceptions are caused by executing instructionszExceptions 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 deliberateJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 10z Unexpected events are, well, unexpected What is an example?z Deliberate events are scheduled by OS or application Why would this be useful?6Categorizing Events (2)Categorizing Events (2)z This gives us a convenient table:UnexpectedDeliberate 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)UnexpectedDeliberateExceptions (sync) fault syscall trapInterrupts (async) interrupt software interruptJanuary 11, 2007 CSE 120 – Lecture 2 – Architectural Support for OSes 11deferred 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?FaultsFaultsz Hardware detects and reports “exceptional” conditionsPage fault unaligned access divide by zeroPage fault, unaligned access, divide by zeroz Upon exception, hardware “faults” (verb) Must save state (PC, regs, mode, etc.) so that the


View Full Document

UCSD CSE 120 - Lecture 2

Documents in this Course
Threads

Threads

14 pages

Deadlocks

Deadlocks

19 pages

Processes

Processes

14 pages

Paging

Paging

13 pages

Processes

Processes

18 pages

Threads

Threads

29 pages

Security

Security

16 pages

Paging

Paging

13 pages

Processes

Processes

32 pages

Paging

Paging

8 pages

Threads

Threads

14 pages

Paging

Paging

13 pages

Paging

Paging

26 pages

Paging

Paging

13 pages

Lecture

Lecture

13 pages

Processes

Processes

14 pages

Paging

Paging

13 pages

Security

Security

17 pages

Threads

Threads

15 pages

Processes

Processes

34 pages

Structure

Structure

10 pages

Lecture 3

Lecture 3

13 pages

Lecture 1

Lecture 1

28 pages

Threads

Threads

15 pages

Paging

Paging

30 pages

Load more
Download Lecture 2
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 2 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 2 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?