interrupts and system
play

Interrupts and System Next Thursdays class has a reading assignment - PDF document

9/7/12 Housekeeping Welcome TA Amit Arya Office Hours posted Interrupts and System Next Thursdays class has a reading assignment Lab 1 due Friday Calls All students should have VMs at this point Email Don


  1. 9/7/12 ¡ Housekeeping ò Welcome TA Amit Arya – Office Hours posted Interrupts and System ò Next Thursday’s class has a reading assignment ò Lab 1 due Friday Calls ò All students should have VMs at this point ò Email Don if you don’t have one Don Porter CSE 506 ò Private git repositories should be set-up Logical Diagram Background: Control Flow Binary Memory pc // x = 2, y = true void printf(va_args) Threads Formats Allocators { User if (y) { //... System Calls Kernel 2 /= x; } RCU File System Networking Sync printf(x); } //... Today’s Lecture Memory CPU Device Management Drivers Scheduler Regular control flow: branches and calls Hardware (logically follows source code) Interrupts Disk Net Consistency Background: Control Flow Lecture goal pc // x = 0, y = true void handle_divzero() ò Understand the hardware tools available for irregular Divide by zero! control flow. { Program can’t make if (y) { progress! ò I.e., things other than a branch in a running program x = 2; 2 /= x; ò Building blocks for context switching, device } management, etc. printf(x); } //... Irregular control flow: exceptions, system calls, etc. 1 ¡

  2. 9/7/12 ¡ Two types of interrupts Intel nomenclature ò Synchronous: will happen every time an instruction ò Interrupt – only refers to asynchronous interrupts executes (with a given program state) ò Exception – synchronous control transfer ò Divide by zero ò System call ò Note: from the programmer’s perspective, these are ò Bad pointer dereference handled with the same abstractions ò Asynchronous: caused by an external event ò Usually device I/O ò Timer ticks (well, clocks can be considered a device) Lecture outline Interrupt overview ò Overview ò Each interrupt or exception includes a number indicating its type ò How interrupts work in hardware ò E.g., 14 is a page fault, 3 is a debug breakpoint ò How interrupt handlers work in software ò This number is the index into an interrupt table ò How system calls work ò New system call hardware on x86 x86 interrupt table x86 interrupt overview Device IRQs 48 = JOS 128 = Linux ò Each type of interrupt is assigned an index from 0—255. System Call System Call ò 0—31 are for processor interrupts; generally fixed by Intel ò E.g., 14 is always for page faults … … … ò 32—255 are software configured 0 31 47 255 ò 32—47 are for device interrupts (IRQs) in JOS Most device’s IRQ line can be configured ò ò Look up APICs for more info (Ch 4 of Bovet and Cesati) ò 0x80 issues system call in Linux (more on this later) Software Configurable Reserved for the CPU 2 ¡

  3. 9/7/12 ¡ Software interrupts Software interrupts, cont ò The int <num> instruction allows software to raise an ò OS sets ring level required to raise an interrupt interrupt ò Generally, user programs can’t issue an int 14 (page fault manually) ò 0x80 is just a Linux convention. JOS uses 0x30. ò An unauthorized int instruction causes a general ò There are a lot of spare indices protection fault ò You could have multiple system call tables for different ò Interrupt 13 purposes or types of processes! ò Windows does: one for the kernel and one for win32k What happens (generally): How it works (HW) ò Control jumps to the kernel ò How does HW know what to execute? ò At a prescribed address (the interrupt handler) ò Where does the HW dump the registers; what does it use ò The register state of the program is dumped on the kernel’s as the interrupt handler’s stack? stack ò Sometimes, extra info is loaded into CPU registers ò E.g., page faults store the address that caused the fault in the cr2 register ò Kernel code runs and handles the interrupt ò When handler completes, resume program (see iret instr.) How is this configured? x86 interrupt table idtr ò Kernel creates an array of Interrupt descriptors in memory, called Interrupt Descriptor Table, or IDT … … … ò Can be anywhere in physical memory ò Pointed to by special register ( idtr ) 0 31 47 255 ò c.f., segment registers and gdtr and ldtr � ò Entry 0 configures interrupt 0, and so on Physical Address of Interrupt Table (Avoids going through page translation) 3 ¡

  4. 9/7/12 ¡ x86 interrupt table Interrupt Descriptor idtr ò Code segment selector ò Almost always the same (kernel code segment) … … … ò Recall, this was designed before paging on x86! ò Segment offset of the code to run 0 31 47 255 ò Kernel segment is “flat”, so this is just the linear address 14 ò Privilege Level (ring) ò Interrupts can be sent directly to user code. Why? Code Segment: Kernel Code Segment Offset: &page_fault_handler //linear addr ò Present bit – disable unused interrupts Ring: 0 // kernel Present: 1 ò Gate type (interrupt or trap/exception) – more in a bit Gate Type: Exception x86 interrupt table Interrupt Descriptors, ctd. idtr ò In-memory layout is a bit confusing ò Like a lot of the x86 architecture, many interfaces were … … … later deprecated ò Worth comparing Ch 9.5 of the i386 manual with inc/ 0 31 47 255 3 mmu.h in the JOS source code Code Segment: Kernel Code Segment Offset: &breakpoint_handler //linear addr Ring: 3 // user Present: 1 Gate Type: Exception How it works (HW) Task State Segment (TSS) ò Another segment, just like the code and data segment ò How does HW know what to execute? ò A descriptor created in the GDT (cannot be in LDT) ò Interrupt descriptor table specifies what code to run and at what privilege ò Selected by special task register (tr) ò This can be set up once during boot for the whole system ò Unlike others, has a hardware-specified layout ò Lots of fields for rarely-used features ò Where does the HW dump the registers; what does it use as the interrupt handler’s stack? ò Two features we care about in a modern OS: ò Specified in the Task State Segment ò 1) Location of kernel stack (fields ss0/esp0) ò 2) I/O Port privileges (more in a later lecture) 4 ¡

  5. 9/7/12 ¡ TSS, cont. Summary ò Simple model: specify a TSS for each process ò Most interrupt handling hardware state set during boot ò Optimization (JOS): ò Each interrupt has an IDT entry specifying: ò Our kernel is pretty simple (uniprocessor only) ò What code to execute, privilege level to raise the interrupt ò Why not just share one TSS and kernel stack per-process? ò Stack to use specified in the TSS ò Linux generalization: ò One TSS per CPU ò Modify TSS fields as part of context switching Comment Lecture outline ò Again, segmentation rears its head ò Overview ò You can’t program OS-level code on x86 without getting ò How interrupts work in hardware your hands dirty with it ò How interrupt handlers work in software ò Helps to know which features are important when ò How system calls work reading the manuals ò New system call hardware on x86 High-level goal Interrupt Handlers ò Respond to some event, return control to the appropriate ò Just plain old kernel code process ò What to do on: ò Network packet arrives ò Disk read completion ò Divide by zero ò System call 5 ¡

  6. 9/7/12 ¡ Example Complication: Stack Stack ò What happens if I’m in an interrupt handler, and another interrupt comes in? Disk RSP RSP Interrupt! ò Note: kernel stack only changes on privilege level change ò Nested interrupts just push the next frame on the stack ò What could go wrong? ò Violate code invariants RIP RIP if (x) { Disk_handler (){ printf(“Boo”); ò Deadlock ... ... } ò Exhaust the stack (if too many fire at once) printf(va_args…){ ... User Kernel Example Bottom Line: Stack Stack ò Interrupt service routines must be reentrant or synchronize Network RSP Interrupt! ò Period. RIP disk_handler (){ Will Hang Forever! lock_kernel(); if (x) { Already Locked!!! ... printf(“Boo”); unlock_kernel(); ... ... net_handler (){ printf(va_args…){ lock_kernel(); ... User Kernel … Hardware interrupt sync. Disabling interrupts ò While a CPU is servicing an interrupt on a given IRQ ò An x86 CPU can disable I/O interrupts line, the same IRQ won’t raise another interrupt until the routine completes ò Clear bit 9 of the EFLAGS register (IF Flag) ò cli and sti instructions clear and set this flag ò Bottom-line: device interrupt handler doesn’t have to worry about being interrupted by itself ò Before touching a shared data structure (or grabbing a ò A different device can interrupt the handler lock), an interrupt handler should disable I/O interrupts ò Problematic if they share data structures ò Like a list of free physical pages… ò What if both try to grab a lock for the free list? 6 ¡

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend