Lecture 2: Architectural (hardware) Support for Operating Systems

Slides:



Advertisements
Similar presentations
Computer-System Structures Er.Harsimran Singh
Advertisements

More on Processes Chapter 3. Process image _the physical representation of a process in the OS _an address space consisting of code, data and stack segments.
1 Exceptions, Interrupts & Traps Operating System Hebrew University Spring 2007.
Tutorial 3 - Linux Interrupt Handling -
Exceptional Control Flow Processes Today. Control Flow Processors do only one thing: From startup to shutdown, a CPU simply reads and executes (interprets)
Chapter 6 Limited Direct Execution
CMPT 300: Operating Systems I Dr. Mohamed Hefeeda
CS 153 Design of Operating Systems Spring 2015 Lecture 3: Intro and Architectural Support for Operating Systems.
CSC 501 Lecture 2: Processes. Von Neumann Model Both program and data reside in memory Execution stages in CPU: Fetch instruction Decode instruction Execute.
Architectural Support for OS March 29, 2000 Instructor: Gary Kimura Slides courtesy of Hank Levy.
Figure 2.8 Compiler phases Compiling. Figure 2.9 Object module Linking.
OS Fall ’ 02 Introduction Operating Systems Fall 2002.
OS Spring’03 Introduction Operating Systems Spring 2003.
1 Last Class: Introduction Operating system = interface between user & architecture Importance of OS OS history: Change is only constant User-level Applications.
OS Spring’04 Introduction Operating Systems Spring 2004.
Exceptions, Interrupts & Traps
1 OS & Computer Architecture Modern OS Functionality (brief review) Architecture Basics Hardware Support for OS Features.
What are Exception and Interrupts? MIPS terminology Exception: any unexpected change in the internal control flow – Invoking an operating system service.
CSE 451: Operating Systems Autumn 2013 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
1 CS503: Operating Systems Part 1: OS Interface Dongyan Xu Department of Computer Science Purdue University.
System Calls 1.
3/11/2002CSE Input/Output Input/Output Control Datapath Memory Processor Input Output Memory Input Output Network Control Datapath Processor.
Protection and the Kernel: Mode, Space, and Context.
Traps and Faults. Review: Mode and Space data user mode kernel mode A B C “kernel space”
CSC 501 Lecture 2: Processes. Process Process is a running program a program in execution an “instantiation” of a program Program is a bunch of instructions.
Architecture Support for OS CSCI 444/544 Operating Systems Fall 2008.
Contact Information Office: 225 Neville Hall Office Hours: Monday and Wednesday 12:00-1:00 and by appointment.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto OS-Related Hardware.
CS 153 Design of Operating Systems Spring 2015 Lecture 2: Intro and Architectural Support for Operating Systems.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
Operating Systems Lecture 7 OS Potpourri Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard. Zhiqing Liu School of Software.
1 CSE451 Architectural Supports for Operating Systems Autumn 2002 Gary Kimura Lecture #2 October 2, 2002.
Lecture Topics: 10/29 Architectural support for operating systems –timers –kernel mode –system calls –protected instructions.
Exceptional Control Flow Topics Exceptions except1.ppt CS 105 “Tour of the Black Holes of Computing”
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
University of Washington Exceptional Control Flow The Hardware/Software Interface CSE351 Winter 2013.
1 Lecture 1: Computer System Structures We go over the aspects of computer architecture relevant to OS design  overview  input and output (I/O) organization.
Interrupts and Exception Handling. Execution We are quite aware of the Fetch, Execute process of the control unit of the CPU –Fetch and instruction as.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
CSCI/CMPE 4334 Operating Systems Review: Exam 1 1.
Chapter 6 Limited Direct Execution Chien-Chung Shen CIS/UD
Of Privilege, Traps, Interrupts & Exceptions Prof. Sirer CS 316 Cornell University.
Introduction to Operating Systems Concepts
Exceptional Control Flow
Introduction to Operating Systems
Exceptional Control Flow
Protection and OS Structure
Exceptional Control Flow
Anton Burtsev February, 2017
Protection of System Resources
Overview of today’s lecture
CS 3305 System Calls Lecture 7.
Exceptional Control Flow
CSE451 Operating Systems Winter 2011
CSE 120 Principles of Operating
CSE 451: Operating Systems Spring 2012 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
CSE 153 Design of Operating Systems Winter 18
Exceptions Control Flow
Architectural Support for OS
CSE 451: Operating Systems Autumn 2004 Module 2 Architectural Support for Operating Systems Hank Levy 1.
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
CSE 451: Operating Systems Winter 2007 Module 2 Architectural Support for Operating Systems Brian Bershad 562 Allen Center 1.
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
Architectural Support for OS
Steve Gribble (for Hank Levy)
Interrupts and System Calls
Introduction and Overview
Presentation transcript:

Lecture 2: Architectural (hardware) Support for Operating Systems Operating Systems ECE344 Lecture 2: Architectural (hardware) Support for Operating Systems Ding Yuan

Content of this lecture Review of introduction Hardware overview A peek at Unix Hardware (architecture) support Summary Ding Yuan, ECE344 Operating System

Review What are the two main responsibilities of OS? Manage hardware resources Provide a clean set of interface to programs Managing resources: Allocation Protection Reclamation Virtualization Questions? Ding Yuan, ECE344 Operating System

Why Start With Hardware? Operating system functionality fundamentally depends upon hardware Key goal of an OS is to manage hardware If done well, applications can be oblivious to HW details Hardware support can greatly simplify – or complicate – OS tasks Early PC operating systems (DOS, MacOS) lacked virtual memory in part because the hardware did not support it Ding Yuan, ECE344 Operating System

So what is inside a computer An abstract overview http://www.youtube.com/watch?v=Q2hmuqS8bwM&feature=related An introduction with a real computer http://www.youtube.com/watch?v=VWzX4MEYOBk Ding Yuan, ECE344 Operating System

A Typical Computer from a Hardware Point of View OS Apps Data OS Apps Data Ding Yuan, ECE344 Operating System

Memory-storage Hierarchy Access Time Typical Capacity 0.3 ns 1 – 16 KB 0.5 ns 2 – 64 MB 100 ns 4 – 64 GB 10,000,000 ns 64 – 4 TB -9 1 nanosecond = 10 second Ding Yuan, ECE344 Operating System

A peek into Unix structure Written by programmer Compiled by programmer Uses library calls (e.g., printf) Ding Yuan, ECE344 Operating System

A peek into Unix structure Example: stdio.h Written by elves Uses system calls Defined in headers Input to linker (compiler) Invoked like functions May be “resolved” when program is loaded. Ding Yuan, ECE344 Operating System

A peek into Unix structure System calls (read, open..) All “high-level” code Ding Yuan, ECE344 Operating System

A peek into Unix structure Bootstrap System initialization Interrupt and exception I/O device driver Memory management Kernel/user mode switching Processor management Ding Yuan, ECE344 Operating System

A peek into Unix structure Cannot execute “protected_instruction”, e.g., directly access I/O device User mode Kernel mode Some systems do not have clear user-kernel boundary User/kernel mode is supported by hardware (why?) Ding Yuan, ECE344 Operating System

Why hardware has to support User/Kernel mode? Imaginary OS code (software-only solution) if ([PC] != protected_instruction) execute(PC); else switch_to_kernel_mode(); Does it work? Ding Yuan, ECE344 Operating System

Why hardware has to support User/Kernel mode? Application’s code: lw $t0, 4($gp) mult $t0, $t0, $t0 lw $t1, 4($gp) ori $t2, $zero, 3 mult $t1, $t1, $t2 add $t2, $t0, $t1 sw $t2, 0($gp) OS: check if next instruction is protected instruction. Ding Yuan, ECE344 Operating System

Why hardware has to support User/Kernel mode? Application’s code: lw $t0, 4($gp) mult $t0, $t0, $t0 lw $t1, 4($gp) ori $t2, $zero, 3 mult $t1, $t1, $t2 add $t2, $t0, $t1 sw $t2, 0($gp) OS: check if next instruction is protected instruction. Performance overhead is too big: OS needs to check every instruction of the application! Simulators Ding Yuan, ECE344 Operating System

Why hardware has to support User/Kernel mode? OS: set-up the environment; load the application Application’s code: lw $t0, 4($gp) mult $t0, $t0, $t0 lw $t1, 4($gp) ori $t2, $zero, 3 mult $t1, $t1, $t2 add $t2, $t0, $t1 sw $t2, 0($gp) Instead, what we really want is to give the CPU entirely to the application Bare-metal execution Any problems? Return to OS after termination; OS: schedule next application to execute.. How can OS check if application executes protected instruction? How can OS know it will ever run again? Ding Yuan, ECE344 Operating System

Why hardware has to support User/Kernel mode? Give the CPU to the user application Why: Performance and efficiency OS will not be executing Without hardware’s help, OS loses control of the machine! Analogy: give the car key to someone, how do you know if he will return the car? This is the one of the most fundamental reasons why OS will need hardware support --- not only for user/kernel mode Questions? Ding Yuan, ECE344 Operating System

Hardware Features for OS 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 Ding Yuan, ECE344 Operating System

Types of Hardware Support Manipulating privileged machine state Protected instructions Manipulate device registers, TLB entries, etc. Generating and handling “events” Interrupts, exceptions, system calls, etc. Respond to external events CPU requires software intervention to handle fault or trap Mechanisms to handle concurrency Interrupts, atomic instructions Ding Yuan, ECE344 Operating System

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 Halt instruction (why?) Ding Yuan, ECE344 Operating System

OS Protection Hardware must support (at least) two modes of operation: kernel mode and user mode 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 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 x86: General Protection Fault Ding Yuan, ECE344 Operating System

Memory Protection OS must be able to protect programs from each other OS must protect itself from user programs We need hardware support Again: once OS gives the CPU to the user programs, OS loses control Ding Yuan, ECE344 Operating System

Memory Protection 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 Ding Yuan, ECE344 Operating System

Hardware Features for OS 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 Ding Yuan, ECE344 Operating System

Events An event is an “unnatural” change in control flow After the OS has booted, all entry to the kernel happens as the result of an event event immediately stops current execution changes mode to kernel mode, event handler is called An event is an “unnatural” change in control flow Events immediately stop current execution Changes mode, context (machine state), or both 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 machine In effect, the operating system is one big event handler Ding Yuan, ECE344 Operating System

OS Control Flow When the processor receives an event of a given type, it transfers control to handler within the OS handler saves program state (PC, registers, etc.) handler functionality is invoked handler restores program state, returns to program Ding Yuan, ECE344 Operating System

Categorizing Events Two kinds of events, interrupts and exceptions Exceptions are caused by executing instructions CPU requires software intervention to handle a fault or trap 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 What is an example? Deliberate events are scheduled by OS or application Why would this be useful? Ding Yuan, ECE344 Operating System

Categorizing Events This gives us a convenient table: Terms may be used slightly differently by various OSes, CPU architectures… No need to “memorize” all the terms 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 Unexpected Deliberate Exceptions (sync) fault syscall trap software interrupt Interrupts (async) interrupt Ding Yuan, ECE344 Operating System

Faults Ding Yuan, ECE344 Operating System

Faults Hardware detects and reports “exceptional” conditions Page fault, divide by zero, unaligned access Upon exception, hardware “faults” (verb) Must save state (PC, registers, mode, etc.) so that the faulting process can be restarted Fault exceptions are a performance optimization Could detect faults by inserting extra instructions into code (at a significant performance penalty) Ding Yuan, ECE344 Operating System

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 SIGSEGV, SIGALRM, SIGTERM, etc. Ding Yuan, ECE344 Operating System

Handling Faults The kernel may handle unrecoverable faults by killing the user process Program faults 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, state dumped to a core file, machine locked up Ding Yuan, ECE344 Operating System

System Calls For a user program to do something “privileged” (e.g., I/O) it must call an OS procedure Known as crossing the protection boundary, or a protected procedure call Hardware provides a system call instruction that: Causes an exception, which vectors to a kernel handler Passes a parameter determining the system routine to call Saves caller state (PC, registers, etc.) so it can be restored Returning from system call restores this state Requires hardware support to: Restore saved state, reset mode, resume execution Ding Yuan, ECE344 Operating System

System Call Functions Process control File management Create process, allocate memory File management Create, read, delete file Device management Open device, read/write device, mount device Information maintenance Get time Programmers generally do not use system calls directly They use runtime libraries (e.g., stdio.h) Why? Ding Yuan, ECE344 Operating System

Function call Compile main () { main: push $10 foo (10); call foo } .. .. foo: .. .. ret Ding Yuan, ECE344 Operating System

System call open: ;Linux convention: ;parameters via registers. mov eax, 5 ; syscall number for open mov ebx, path ; ebx: first parameter mov ecx, flags ; ecx: 2nd parameter mov edx, mode ; edx: 3rd parameter int 80h open (path, flags, mode); open: ; FreeBSD convention: ; parameters via stacks. push dword mode push dword flags push dword path mov eax, 5 push dword eax ; syscall number int 80h add esp, byte 16 More information: http://www.int80h.org Ding Yuan, ECE344 Operating System

Directly using system call? Write assembly code Hard Poor portability write different version for different architecture write different version for different OSes Application programmers use library Libraries written by elves Ding Yuan, ECE344 Operating System

System Call Firefox: open() Trap to kernel mode, save state User mode Restore state, return to user level, resume execution Trap handler open read handler in vector table open() kernel routine Ding Yuan, ECE344 Operating System

Steps in making a syscall Ding Yuan, ECE344 Operating System

System Call Issues What would happen if the kernel did not save state? Why must the kernel verify arguments? Why is a table of system calls in the kernel necessary? Ding Yuan, ECE344 Operating System

Interrupts Interrupts signal asynchronous events I/O hardware interrupts Hardware timers Two flavors of interrupts Precise: CPU transfers control only on instruction boundaries Imprecise: CPU transfers control in the middle of instruction execution What the heck does that mean? OS designers like precise interrupts, CPU designers like imprecise interrupts Why? Ding Yuan, ECE344 Operating System

Interrupt Illustrated User Mode Mode bit = 1 User process Resume process Kernel Mode Mode bit = 0 Return Mode bit = 1 Suspend user process Execute OS’s interrupt handler Save user process’s state Execute device driver Restore state Clear interrupt Raise Interrupt Device Ding Yuan, ECE344 Operating System

How to find interrupt handler? Hardware maps interrupt type to interrupt number OS sets up Interrupt Descriptor Table (IDT) at boot Also called interrupt vector IDT is in memory Each entry is an interrupt handler OS lets hardware know IDT base Hardware finds handler using interrupt number as index into IDT handler = IDT[intr_number] Ding Yuan, ECE344 Operating System

Timer The timer is critical for an operating system It is the fallback mechanism by which the OS reclaims control over the machine Timer is set to generate an interrupt after a period of time Setting timer is a privileged instruction When timer expires, generates an interrupt Handled by kernel, which controls resumption context Basis for OS scheduler (more later…) Prevents infinite loops OS can always regain control from erroneous or malicious programs that try to hog CPU Also used for time-based functions (e.g., sleep()) Ding Yuan, ECE344 Operating System

I/O Control I/O issues Initiating an I/O Completing an I/O Special instructions Memory-mapped I/O Device registers mapped into address space Writing to address sends data to I/O device Ding Yuan, ECE344 Operating System

I/O Completion Interrupts are the basis for asynchronous I/O OS initiates I/O Device operates independently of rest of machine Device sends an interrupt signal to CPU when done OS maintains a vector table containing a list of addresses of kernel routines to handle various events CPU looks up kernel address indexed by interrupt number, context switches to routine Ding Yuan, ECE344 Operating System

I/O Example 1. Ethernet receives packet, writes packet into memory 2. Ethernet signals an interrupt 3. CPU stops current operation, switches to kernel mode, saves machine state (PC, mode, etc.) on kernel stack 4. CPU reads address from vector table indexed by interrupt number, branches to address (Ethernet device driver) 5. Ethernet device driver processes packet (reads device registers to find packet in memory) 6. Upon completion, restores saved state from stack Ding Yuan, ECE344 Operating System

Interrupt Questions Interrupts halt the execution of a process and transfer control (execution) to the operating system Can the OS be interrupted? (Consider why there might be different IRQ levels) Interrupts are used by devices to have the OS do stuff What is an alternative approach to using interrupts? What are the drawbacks of that approach? Ding Yuan, ECE344 Operating System

Alternative approach Polling Problems? Analogy: Polling: keeps checking the email every 30 seconds Interrupt: when email arrives, give me a ring while (Ethernet_card_queue_is_empty) ; // Ethernet card received packets. handle_packets(); Ding Yuan, ECE344 Operating System

Summary Protection System calls Exceptions Interrupts User/kernel modes Protected instructions System calls Used by user-level processes to access OS functions Access what is “in” the OS Exceptions Unexpected event during execution (e.g., divide by zero) Interrupts Timer, I/O Ding Yuan, ECE344 Operating System

Summary (2) After the OS has booted, all entry to the kernel happens as the result of an event event immediately stops current execution changes mode to kernel mode, event handler is called When the processor receives an event of a given type, it transfers control to handler within the OS handler saves program state (PC, registers, etc.) handler functionality is invoked handler restores program state, returns to program Ding Yuan, ECE344 Operating System

Architecture Trends Impact OS Design Processor Single core to multi-core OS must better handle concurrency Network Isolation to dial-up to LAN to WAN OS must devote more efforts to communications Disconnected to wired to wireless OS must manage connectivity more Isolated to shared to attacked OS must provide more security/protection Mobile/battery-operated OS must pay attention to energy consumption Ding Yuan, ECE344 Operating System

May you live in Interesting Times Multicores Smart phones Tapesdisksflash memory.. 3G, 4G.. Cloud Wearable computers Virtual reality Motion capturing device .. Ding Yuan, ECE344 Operating System