Duke CPS 196 - Machines and Virtualization

Unformatted text preview:

Machines and VirtualizationMachines and VirtualizationSystems and NetworksJeff ChaseSpring 2006Memory Protection Memory Protection Paging Virtual memory provides protection by:• Each process (user or OS) has different virtual memory space.• The OS maintain the page tables for all processes.• A reference outside the process allocated space cause an exception that lets the OS decide what to do.• Memory sharing between processes is done via different Virtual spaces but common physical frames.[Kedem, CPS 104, Fall05]Architectural Foundations of OS KernelsArchitectural Foundations of OS Kernels• One or more privileged execution modes (e.g., kernel mode)protected device control registersprivileged instructions to control basic machine functions• System call trap instruction and protected fault handlingUser processes safely enter the kernel to access shared OS services.• Virtual memory mappingOS controls virtual-physical translations for each address space.• Device interrupts to notify the kernel of I/O completion etc.Includes timer hardware and clock interrupts to periodically return control to the kernel as user code executes.• Atomic instructions for coordination on multiprocessorsMemory and the CPUMemory and the CPU02ncode libraryOS dataOS codeProgram AdataDataProgram BDataregistersCPUR0RnPCmain memoryxxKernel ModeKernel Mode02ncode libraryOS dataOS codeProgram AdataDataProgram BDataregistersCPUR0RnPCmain memoryxxmodeCPU mode (a field in some status register) indicates whether the CPU is running in a userprogram or in the protected kernel.Some instructions or register accesses are only legal when the CPU is executing in kernel mode.physical address spaceIntroduction to Virtual AddressingIntroduction to Virtual AddressingtextdataBSSuser stackargs/envkerneldatavirtualmemory(big?)physicalmemory(small?)virtual-to-physical translationsUser processes address memory through virtual addresses.The kernel and the machine collude to translate virtual addresses to physical addresses.The kernel controls the virtual-physical translations in effect for each space.The machine does not allow a user process to access memory unless the kernel “says it’s OK”.The specific mechanisms for implementing virtual address translation are machine-dependent.Processes and the KernelProcesses and the Kerneldata dataprocesses in private virtual address spacessystem call traps...and upcalls (e.g., signals)shared kernel code and data in shared address spaceThreads or processes enter the kernel for services.The kernel sets up process execution contexts to “virtualize” the machine.CPU and devices force entry to the kernel to handle exceptional events.The KernelThe Kernel• Today, all “real” operating systems have protected kernels.The kernel resides in a well-known file: the “machine”automatically loads it into memory (boots) on power-on/reset. Our “kernel” is called the executive in some systems (e.g., XP). • The kernel is (mostly) a library of service procedures shared by all user programs, but the kernel is protected:User code cannot access internal kernel data structures directly, and it can invoke the kernel only at well-defined entry points (system calls).• Kernel code is like user code, but the kernel is privileged:The kernel has direct access to all hardware functions, and defines the machine entry points for interrupts and exceptions.Protecting Entry to the KernelProtecting Entry to the KernelProtected events and kernel mode are the architectural foundations of kernel-based OS (Unix, XP, etc).•The machine defines a small set of exceptional event types.•The machine defines what conditions raise each event.• The kernel installs handlers for each event at boot time.e.g., a table in kernel memory read by the machineThe machine transitions to kernel mode only on an exceptional event.The kernel defines the event handlers.Therefore the kernel chooses what code will execute in kernel mode, and when.userkernelinterrupt orexceptiontrap/returnExample: System Call TrapsExample: System Call TrapsUser code invokes kernel services by initiating system call traps.• Programs in C, C++, etc. invoke system calls by linking to a standard library of procedures written in assembly language.the library defines a stub or wrapper routine for each syscallstub executes a special trap instruction (e.g., chmk or callsys or int)syscall arguments/results passed in registers or user stackread() in Unix libc.a library (executes in user mode):#define SYSCALL_READ 27 # code for a read system callmove arg0…argn, a0…an # syscall args in registers A0..ANmove SYSCALL_READ, v0 # syscall dispatch code in V0callsys # kernel trapmove r1, _errno # errno = return statusreturnAlpha CPU architectureFaultsFaultsFaults are similar to system calls in some respects:• Faults occur as a result of a process executing an instruction.Fault handlers execute on the process kernel stack; the fault handler may block (sleep) in the kernel.• The completed fault handler may return to the faulted context.But faults are different from syscall traps in other respects:• Syscalls are deliberate, but faults are “accidents”.divide-by-zero, dereference invalid pointer, memory page fault• Not every execution of the faulting instruction results in a fault.may depend on memory state or register contentsThe Role of EventsThe Role of EventsA CPU event is an “unnatural” change in control flow.Like a procedure call, an event changes the PC.Also changes mode or context (current stack), or both.Events do not change the current space!The kernel defines a handler routine for each event type.Event handlers always execute in kernel mode.The specific types of events are defined by the machine.Once the system is booted, every entry to the kernel occurs as a result of an event.In some sense, the whole kernel is a big event handler.CPU Events: Interrupts and ExceptionsCPU Events: Interrupts and ExceptionsAn interrupt is caused by an external event.device requests attention, timer expires, etc.An exception is caused by an executing instruction.CPU requires software intervention to handle a fault or trap.unplanned deliberatesync fault syscall trapasync interrupt ASTcontrol flowevent handler (e.g., ISR: Interrupt Service Routine)exception.ccAST: Asynchronous System TrapAlso called a software interrupt or an Asynchronous or Deferred Procedure Call (APC or DPC)Note: different “cultures” may use some of these terms (e.g.,


View Full Document

Duke CPS 196 - Machines and Virtualization

Download Machines and Virtualization
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 Machines and Virtualization 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 Machines and Virtualization 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?