Unformatted text preview:

CSE 120 Principles of Operating Systems Spring 2009 Lecture 2 Architectural Support for Operating Systems Geoffrey M Voelker Administrivia Mailing list Homework 1 Due 4 9 Project 0 You should be getting mail on the list If not let me know Due 4 9 done individually Project groups April 2 2009 When you have chosen groups send your group info to Will wychang cs ucsd edu CSE 120 Lecture 2 Architectural Support for OSes 2 Why Start With Architecture Operating system functionality fundamentally depends upon 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 bag Architectural support can greatly simplify or complicate OS tasks April 2 2009 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 CSE 120 Lecture 2 Architectural Support for OSes 3 Architectural Features for OS Features that directly support the OS include April 2 2009 Protection kernel user mode Protected instructions Memory protection System calls Interrupts and exceptions Timer clock I O control and operation Synchronization CSE 120 Lecture 2 Architectural Support for OSes 4 Types of Arch Support Manipulating privileged machine state Generating and handling events Protected instructions Manipulate device registers TLB entries etc Interrupts exceptions system calls etc Respond to external events CPU requires software intervention to handle fault or trap Mechanisms to handle concurrency April 2 2009 Interrupts atomic instructions CSE 120 Lecture 2 Architectural Support for OSes 5 Protected Instructions 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 Page table pointers page protection TLB management etc Manipulate protected control registers Kernel mode interrupt level April 2 2009 Halt instruction why CSE 120 Lecture 2 Architectural Support for OSes 6 OS Protection 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 April 2 2009 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 prevented CSE 120 Lecture 2 Architectural Support for OSes 7 Memory 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 memory protection mechanisms Base and limit registers Page table pointers page protection TLB Virtual memory Segmentation Manipulating memory management hardware uses protected privileged operations April 2 2009 CSE 120 Lecture 2 Architectural Support for OSes 8 Events 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 April 2 2009 In effect the operating system is one big event handler CSE 120 Lecture 2 Architectural Support for OSes 9 Categorizing Events Two kinds of events interrupts and exceptions Exceptions are caused by executing instructions Interrupts are caused by an external event Device finishes I O timer expires etc Two reasons for events unexpected and deliberate Unexpected events are well unexpected CPU requires software intervention to handle a fault or trap What is an example Deliberate events are scheduled by OS or application April 2 2009 Why would this be useful CSE 120 Lecture 2 Architectural Support for OSes 10 Categorizing Events 2 This gives us a convenient table Unexpected Deliberate Exceptions sync fault syscall trap Interrupts async interrupt software interrupt 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 Will cover faults system calls and interrupts next April 2 2009 Does anyone remember from CSE 141 what a software interrupt is CSE 120 Lecture 2 Architectural Support for OSes 11 Faults 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 garbage collection copy on write Fault exceptions are a performance optimization April 2 2009 Could detect faults by inserting extra instructions into code at a significant performance penalty CSE 120 Lecture 2 Architectural Support for OSes 12 Handling Faults 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 changes 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 April 2 2009 CSE 120 Lecture 2 Architectural Support for OSes 13 Handling Faults 2 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 Kernel is halted


View Full Document

UCSD CSE 120 - Architectural Support for Operating Systems

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

Lecture 2

Lecture 2

13 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
Loading Unlocking...
Login

Join to view Architectural Support for Operating Systems 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 Architectural Support for Operating Systems 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?