CS5460: Operating Systems Lecture 2: OS Hardware Interface - - PowerPoint PPT Presentation

CS 5460: Operating Systems Lecture 2

CS5460: Operating Systems

Lecture 2: OS – Hardware Interface

(Chapter 2)

CS 5460: Operating Systems Lecture 2

 Course web page: – http://www.eng.utah.edu/~cs5460/  CADE lab: – WEB L224 and L226 – http://www.cade.utah.edu/ – Projects will be on Linux machines in CADE – You don’t need to go there, just ssh in  Join the class mailing list – Go to: https://sympa.eng.utah.edu/sympa/ – So far 30 out of 61 have subscribed

CS 5460: Operating Systems Lecture 2

Last Time

 OS History – Mainframe era – Minicomputer era – PC era – Ubiquitous era  Basic OS principles apply over the entire 60-year

history

– Concurrency – Resource management – Providing usable abstractions – Hiding complexity – Etc.

CS 5460: Operating Systems Lecture 2

Operating System Organization

CS 5460: Operating Systems Lecture 2

What is an Operating System?

 Interface between user and hardware

– Exports simpler “virtual machine” interface – Hides ugly details of real hardware

 Manages shared resources

– CPU, memory, I/O devices, … – Ensure fairness – Protect processes from one another

 Provides common services

– File system, VM, CPU scheduling, …

 OS design reacts to HW changes

– What OS can do dictated by architecture – Arch support (or lack thereof) can greatly simplify (of complicate) OS design – Example: Early PCs, Motorola 68000

Hardware Operating System User Applications

Virtual Machine Interface Physical Machine Interface

CS 5460: Operating Systems Lecture 2

Modern OS Functionality 1

 Provides a “virtual processor” for application

code

– Clean up after an application when it finishes – Applications are isolated from each other by default – Can communicate (using the OS) when desired  Concurrency – Overlap I/O and computation – even for a single thread – Optionally, multiple threads – even for a single processor – Support running across multiple processors  Manage I/O devices – OS usually sees an asynchronous interface (initiate -> interrupt) – OS usually provides a synchronous interface

CS 5460: Operating Systems Lecture 2

Modern OS Functionality 2

 Memory management – Provides a virtual address space for each process – Moves data between DRAM and disk – OS decides how much memory each application gets  Files – Fast access to slow storage devices – Coherence model  Network – OS provides a high-level interface to the Internet  Security – OS implements a “security policy”  Other: – Accounting, logging, error recovery, …

CS 5460: Operating Systems Lecture 2

Generic Computer Architecture

Memory Controller I/O bus adapter (e.g., PCI, SCSI)

DRAM Disk ctlr Serial ctlr Network controller

… …

L1$ L2$

tag tags

I/O bus System bus TLB/MMU

Physical addrs

CPU Core

Virtual addrs Trap Interrupts RDs/WRs

 CPU: ALUs, pipeline, LD/ST, …  Memory: virtual vs physical addrs  System bus

– Split transaction, addr/data/IO/cntl – Separate “interrupt” lines

 Bus adapter

– Converts system bus à à PCI/SCSI/…

 Device controllers

– CPU writes to mem-mapped IO regs – Devices signal CPU via interrupts

 Things to consider:

– Interrupts and traps – Memory-mapped I/O devices – VA à à PA translation – DMA

CS 5460: Operating Systems Lecture 2

OS Abstractions of HW

Hardware Resource OS abstraction CPU Processes / Threads Main memory Address spaces Disk File system Network Sockets / ports Devices Virtual devices

CS 5460: Operating Systems Lecture 2

HW Support for OS Abstractions

OS Service Hardware Support Isolation between processes Kernel/user mode Protected instructions Memory management unit Virtual memory MMU / TLB System calls Traps Asynchronous I/O Interrupts / DMA CPU scheduling / accounting Timer interrupts Synchronization Atomic instructions Question: Which pieces of HW support are truly necessary?

CS 5460: Operating Systems Lecture 2

Typical OS Structure

 User-level

– Applications – Libraries: many common “OS” functions – Example: malloc() vs sbrk()

 Kernel-level

– Top-level: machine independent – Bottom-level: machine dependent – Runs in protected mode – Need a way to switch (user ßà ßà kernel)

 Hardware-level

– Device maker exports known interface – Device driver initiates operations by writing to device registers – Devices use interrupts to signal completion – DMA (offloads work, but has restrictions)

Hardware

OS kernel

User Apps Libs

Thrd | File | VM | SIG CPU | Disk | Mem | Int

Trap Direct manipulation I/O regs DMA Interrupts DMA

CS 5460: Operating Systems Lecture 2

Virtual Address Space (Simplified)

 Parts of the address space: – Code: binary image of program – Data/BSS: Static variables (globals) – Heap: explicitly alloc’d data (malloc) – Stack: implicitly alloc’d data – I/O registers: not shown  Huge unmapped areas exist,

especially on 64-bit

 Small unmapped region around 0  Kernel mapped into all processes  Question: How might we support

shared libraries?

 MMU hardware: – Remaps VAs to PAs – Supports read-only, supervisor-only – Detects accesses to unmapped regions

Kernel code segment Kernel data segment

Kernel heap

User code segment User data segment User heap User stack segment

Supervisor-only User mode

Read Only Read Only

0x00000000 0x80000000 0xffffffff

CS 5460: Operating Systems Lecture 2

Kernel Mode vs User Mode

 Some instructions can only be used in kernel mode – Direct access to I/O devices (typically) – Instructions to manipulate VAà àPA mappings and TLB – Enable/disable interrupts – Halt the machine  Architecture typically supports: – Status bit in protected processor register indicating mode – Restricts ability to perform certain instructions if not kernel mode  How do user applications get access to protected

instructions?

– Trap or interrupt à à indirect jump via OS-managed function table – System call typically implemented with special TRAP instruction

CS 5460: Operating Systems Lecture 2 foo: … movl r1, (arg1) movl r0, #foo syscall …

 User applications make system calls

to execute privileged instructions

 Anatomy of a system call:

– Program puts syscall params in registers – Program executes a trap: » Minimal processor state (PC, PSW) pushed on stack » CPU switches mode to KERNEL » CPU vectors to registered trap handler in the OS kernel – Trap handler uses param to jump to desired handler (e.g., fork, exec, open, …) – When complete, reverse operation » Place return code in register » Return from exception

Anatomy of a System Call

syscallhdlr(){ … switch (r0){ … case: foo r0 ß ß foo(…); } asm(“ret”); } foo() { … return res; } User Kernel

CS 5460: Operating Systems Lecture 2

System Calls

 Arguments passed in registers: (Why?) – Integer constants (e.g., buffer size, file offset, fileid) – Pointers to blocks of memory (e.g., strings, file buffers, …) – Handles (e.g., file handle, socket handle, …)  OS typically returns: – Return code (value of –1 often denotes error) – Other results written into buffers in user space – You should always (always!) check syscall return values  Principle: Dialogue between user-mode and kernel

should be semantically simple

– Simpler interfaces easier to work with – Simpler interfaces easier to implement correctly – Simpler interfaces tend to be easier to make efficient

CS 5460: Operating Systems Lecture 2

System Call Example

Source

void foo (void) { write(1, “hello\n”, 6); }

Assembly Code

<main>: pushq %rax mov $0x6,%edx mov $0x694010,%esi mov $0x1,%edi callq libc_write xorl %eax,%eax popq %rdx ret <libc_write>: mov $0x1,%eax syscall cmp $0xfffffffffffff001,%rax jae <__syscall_error> retq  Q: Where do all the magic

numbers in the assembly come from?

Note: For this class you will need to be able to read x86 and x86-64 assembly code

CS 5460: Operating Systems Lecture 2

Traps

 Architecture detects special events:

– trap instruction – invalid memory access – floating point exception – privileged instruction by user mode code – …

 When processor detects condition:

– Save minimal CPU state (PC, sp, …) – done by hardware – Switches to KERNEL mode – Transfers control to trap handler » Indexes trap table w/ trap number » Jumps to address in trap table (*) » Handler saves more state and may disable interrupts – RTE instruction reverses operation 0x0082404 0x0084d08 0x008211c 0x0082000 …

Illegal address Mem Violation Illegal instruction System call

TRAP VECTOR:

Here, 0x82404 is address of handle_illegal_addr().

Important from Today

 HW provides support for OS abstractions – Make them possible to implement – Make them easier to implement – Make them more efficient  User programs run in processes – Each see its own virtual address space  Kernel has a very different view of memory  Modern processors support (at least) two modes – User mode and kernel mode  The kernel is not a process  User programs trap into kernel mode to access OS

functionality

CS 5460: Operating Systems Lecture 2