L 4 Linux Porting Optimizations
|
|
- Opal Robertson
- 2 years ago
- Views:
Transcription
1 L 4 Linux Porting Optimizations Adam Lackorzynski Technische Universität Dresden Faculty of Computer Science Operating Systems Group March 2004
2
3 Contents 1 Introduction Terminology Document Structure Acknowledgments Fundamentals and Related Work System Architecture Environments L4 Microkernels Past L 4 Linux Development Linux in User Level MkLinux Xen User-Mode-Linux FAUmachine P4/Linux Other Approaches Design Traditional L 4 Linux design The Linux Server Interrupts Signalling System-Call Emulation Scheduling Memory Time Accounting Linux Threads
4 4 CONTENTS Summary Microkernel Modifications Ex-Regs Across Tasks Exceptions L 4 Linux Modifications Sequential Activity Timeout-Driven Flow Interrupting User Processes Mapping Helper Task Mapping Linux Threads to L4 Threads Summary Implementation Fiasco Microkernel Modifications l4_inter_task_ex_regs UTCBs Exception IPC Page Faults and UTCBs The Linux Port Exception handling User Mapped Page Signalling Process Starting Timer Interrupt Scheduling Fiasco-UX and Device Virtualization Fiasco-UX Input Output Linux Frame Buffer Driver Other Device Virtualization Evaluations First Impressions Source Code Reduction Performance Comparisons Benchmarking Environment IPC Performance
5 CONTENTS Page-fault performance Exception Delivery System-Call Performance Overall System Performance Future Work 47 7 Summary 51 A Glossary 53
6 6 CONTENTS
7 List of Figures 2.1 DROPS architecture Overview of the traditional L 4 Linux design User process interruption Data structures for thread to user process mappings Design overview for L 4 Linux UTCB layout on the x86 architecture Directory layout in the Linux tree Input output system for Fiasco-UX IPC performance comparisons Page-fault performance Exception delivery performance System-call benchmark Linux kernel compile benchmark
8 8 LIST OF FIGURES
9 Chapter 1 Introduction For years L 4 Linux has been available to the L4 community [27]. Starting from the initial port [21] it has gone through various Linux versions and has proven to be helpful for a number of projects or even made them possible. The first L4 microkernel [29] was designed with performance as the main goal. L 4 Linux, a port of Linux to run on top of L4, showed that L4 is sufficiently versatile to run Linux as a user program on it, with only a negligible performance loss [17]. The initial L4 interface was the V2 interface. Over the time, it has gone through two revisions, one called X.0, with small changes to the V2 interface. With the X.2 specification the interface was completely revised, especially addressing the portability of the L4 interface. L 4 Linux has been adapted to all L4 interfaces, L 4 Linux-2.2, a port of Linux-2.2, also runs on X.0 kernels, L 4 Linux-2.4 supports all three interfaces. The overall structure of L 4 Linux has not changed with these adaptations. Still, the L4 interface lacks properties like communication control and a more general rights management scheme. This functionality is especially needed to build secure systems. Broad modifications are being discussed to come up with a new interface specification covering the addressed points. Nevertheless, L4 is fully functional for non-secure and robust systems. L 4 Linux will be affected by these modifications as well and benefit from the newly available possibilities in its design. L 4 Linux, as a system that has to control other address spaces, can make use of the widened rights control and avoid the usage of helper constructs. Additionally, advanced means for communication control will improve L 4 Linux s worthiness in secure systems. This work has the goal to port the current Linux revision, 2.6, to L4 and explore new, simplified ways in the design of L 4 Linux. One methodology is to explicitly include modifying the microkernel by experimentally implementing some of the features planned for the next microkernel revisions. 1.1 Terminology Discussing L 4 Linux always includes at least two kernels, the microkernel and the Linux kernel. Both have tasks, threads, processes, inter-process communication and so on, generally they share terms in identical areas. To relief you of the confusion placed in this mixture, these terms shall be defined as follows. The kernel refers to the microkernel and the Linux server to the Linux system kernel. A thread denotes an L4 thread, a Linux thread is a thread in a Linux context. A task is an 9
10 10 CHAPTER 1. INTRODUCTION address space in the L4 context, which includes at least one thread. Process or user process refers to Linux user processes. Differing meanings are stated explicitly in the text by either prefixed restrictions or further explanations. 1.2 Document Structure This document continues with a chapter about the fundamentals needed for this work, as well as related work done on user level Linux implementations. Chapter 3 discusses changes to the microkernel as well as to L 4 Linux itself to simplify its design. Chapter 4 explains the implementation of a few aspects from the previous chapter. Results will be presented in Chapter 5. Chapter 6 on page 47 gives an outlook to future areas of work that will, can, or should be done. The document closes with a summary. 1.3 Acknowledgments I like to thank Prof. Hermann Härtig and the Operating Systems Group of the University of Dresden for giving me the opportunity to work with such a fantastic group. I especially like to thank Alexander Warg and Frank Mehnert for their invaluable help on the implementation of the Fiasco modifications. Udo Steinberg deserves many thanks for his incredible work on Fiasco-UX, which helped me a lot. I also like to thank everyone who has proofread this document for their useful feedback and recommendations. Finally, many thanks go to my family for giving me the possibility to study at the university and their constant support as well as to my friends for their incessant encouragement.
11 Chapter 2 Fundamentals and Related Work This chapter will explain fundamentals this work is based on and related work with similar goals. 2.1 System Architecture The work on L 4 Linux is usually done in the context of DROPS, the Dresden Real-time OPerating System [16]. The DROPS project aims to build a system where real-time programs can run side by side with non-real-time applications without violating properties promised to the real-time programs. Examples of real-time components may be disk drivers or network servers. Other components are built on top of these services, examples include filesystems or video players. L 4 Linux is located in the non-real-time part of DROPS because it provides the environment to run unmodified Linux applications in the system where no real-time guarantees can be given. The non-real-time part of the system receives the resources that are not utilized by the real-time part. Figure 2.1 on the next page shows the structure of a DROPS system. It is important to note that the L 4 Linux system uses underlying system services in the same way as other L4 applications. Additionally, L 4 Linux may use the higher-level L4 services. For example if a network server will drive the network card of the system, L 4 Linux must use this L4 server for network communication because only one program can drive one particular hardware device at a time. Real-time-capable L4 servers generally also offer their services to non-real-time applications and schedule their clients according to the available resources. 2.2 Environments The L4 API is designed to be minimal and provides only simple functions to the userlevel applications [31]. It is tedious to work with the pure L4 API for bigger applications. To increase application development productivity, supporting libraries, system services and tools are needed. This collection includes a C library, memory management, thread management, program loading, event handling, and an interface definition language along with a stub generator and others. L4Env [26] provides the needed libraries and services by abstracting L4 concepts to higher levels. For example it provides a thread library to handle threads within an application 11
12 12 CHAPTER 2. FUNDAMENTALS AND RELATED WORK Figure 2.1: DROPS architecture in a microkernel-independent way. Applications developed with this library are supposed to run on any L4 microkernel as long as the thread library is available for this particular kernel. Another example is the data-space manager that manages memory objects and provides them to clients as data-spaces, an abstraction of memory objects of arbitrary size, which can be mapped as a whole or in parts to L4 programs. The data-space concept is supposed to abstract the memory management in a way that it is portable between different memory architectures but retains the needed fine-grained control and flexibility. 2.3 L4 Microkernels The whole system runs on an L4 microkernel. L4 microkernels have gone through several revisions starting with the initial version by Jochen Liedtke written entirely in assembly language [29] and implementing the Version 2 interface [30]. The Operating Systems Group in Dresden developed Fiasco [11], a microkernel that is written in C++ for better maintainability and also implements the Version 2 interface. Fiasco is designed to be extremely preemptive by using special locking mechanisms making it well suited for realtime systems [22]. Fiasco is available under the terms of the GNU Public License [15] and is used as a basis for the DROPS project. Over the time, platform portability came into the focus of the L4 community, an attribute that neither the original kernel nor the Version 2 API interface addresses. Jochen Liedtke designed the original V2 API in a way that it is extremely tailored to the x86 architecture to achieve the best possible performance. This customized design made it difficult for other architectures to exploit the full capabilities of the hardware. To address a row of insufficiencies the original kernel interface was slightly modified in a small step producing the X.0 interface [52]. Summarized, the changes reduced the size of a thread ID to have more space for message registers in IPCs. To achieve better portability the interface specification was completely revised and called Version X.2 [53]. The X in the version name stands for
13 2.4. PAST L 4 LINUX DEVELOPMENT 13 experimental. Currently, implementations for all L4 APIs exist as well as for different architectures. The main ones are Fiasco and L4Ka::Pistachio [36]. Fiasco currently implements the V2 and X.0 API and runs on the x86 as well as the ARM architecture. Support for the X.2 API is currently being added to Fiasco. L4Ka::Pistachio is written in C++, implements the X.2 API and was ported to the x86, IA64, ARM, MIPS, PowerPC and other architectures. Besides the already mentioned implementations there are other ones as well. L4Ka::Hazelnut is the predecessor of L4Ka::Pistachio, implementing the X.0 specification and is also written in C++. Its development has been discontinued in favor of L4Ka::Pistachio. There are older experimental kernels for different single architectures, like for Alpha or MIPS. All L4 microkernels have been developed and are mainly used in university and research environments but there are also commercially developed versions. One is P4, a mainly V2 compatible microkernel developed by the SYSGO AG [46]. A list of different implementation of the L4 microkernel interface can be found at [25]. 2.4 Past L 4 Linux Development The first implementation of L 4 Linux was done by the Operating Systems Group in Dresden in 1996 and based on Linux 2.0. Michael Hohmuth wrote his master s thesis about this port [21]. Results of the work have also been presented at the 16th SOSP conference 1997 [17]. Later L 4 Linux has been brought up to date with Linux 2.2. Both ports support the original L4 V2 API, the 2.2 port additionally supports the X.0 API. L 4 Linux-2.4 marks a new milestone as it introduces support for the X.2 API as well as support for symmetric multiprocessors (SMP). Additionally it can run as an application in L4Env [28], which integrates it nicely into DROPS. 2.5 Linux in User Level In the past there have been other approaches to port Linux to run in user level. There are different ways to accomplish this, one being full machine emulation and full virtualization to run unmodified operating systems on it. Other approaches modify the guest operating system in different grades and use varying host systems. A few of the approaches that modify the guest operating system will be explained and a list of ways to run unmodified operating systems will be given MkLinux MkLinux is a port of Linux to the Mach 3 microkernel and was presented in early 1996 [6]. Mach was developed at Carnegie Mellon University [1]. The design of MkLinux is similar to L 4 Linux. Linux runs as a server and user processes in separate address spaces. Exceptions including system calls are redirected to the Linux server using Mach RPC. MkLinux does not map code into each user process address space. To manage the memory for each user process in an efficient way the server has to map the memory of every user process into its own address space, giving the server easy access to it. Signals are delivered through a fake interrupt mechanism, where the server gains control over the user processes and forces
14 14 CHAPTER 2. FUNDAMENTALS AND RELATED WORK them to handle their signals. Overall, MkLinux is slower compared to other solutions like L 4 Linux, mainly due to the design and performance insufficiencies of the underlying Mach kernel [17] Xen Xen [3] is an architecture that partitions resources of a host computer to run guest operating systems in the partitions. It is targeted for the x86 architecture and the port of Linux 2.4 is called XenoLinux. The approach of Xen is called paravirtualization [54, 55] because it does not provide a fully virtualized environment for its guest operating systems. Instead, guest operating systems need to be modified slightly to run on Xen. Full virtualization on the x86 architecture is hard to achieve as certain supervisor instructions do not trap in unprivileged modes. Full virtualization can be achieved but induces a higher complexity and lower performance. Another problem with full virtualization is device emulation where certain hardware devices like network cards or disks need to be emulated. The approach of Xen is to provide a nearly complete virtual machine and to adapt the guest OS to this paravirtualized system where full virtualization is too expensive and can be easily achieved by modifying the guest operating system. Communication with other systems is done with custom drivers, which use the best possible way like shared memory for data exchange. So by modifying the guest system it is possible to avoid the cost of full virtualization both in performance loss and code complexity in the monitor. Of course, the modifications in the guest OS have to be accounted for as well but they are smaller than the added complexity in the virtual machine monitor (VMM). L 4 Linux can also be seen as a paravirtualized system as it modifies Linux to run on an environment that differs from the x86 in certain aspects. The major difference of L4 and Xen is that Xen is targeted at ISPs or similar organizations, which want to use their hardware efficiently while giving customers their own machines. Xen is a VMM with no further abstractions; it can only be a platform for full operating systems like Linux but it cannot offer a system with its own applications supporting certain properties like microkernels User-Mode-Linux User-Mode-Linux [48], or UML, is a port of Linux to the Linux user level, it runs Linux inside Linux. As the main techniques UML uses the ptrace system call and signals to intercept exceptions and system calls and to execute code in user processes. Currently, UML supports two modes of operation, one can run on an unmodified host kernel (called tt mode), the other on a modified host kernel (called skas mode). Modifying the host kernel adds certain features to it to improve the performance of UML. In the tt mode each UML process has its own process in the host system. UML processes are traced by the tracing thread that cancels their system calls and causes them to enter the UML kernel. The UML kernel is mapped in the upper part of each UML process. This design has several drawbacks. By default, the UML kernel is mapped writable into the address space of the UML processes imposing a tremendous security risk like breaking out of the UML system. With the jail mode the UML kernel is mapped read-only, which fixes most of the security concerns but induces an even greater performance loss. The skas mode puts the UML kernel in another address space solving the security problems described previously. Additionally, it currently comes with a patch for the Linux host
15 2.5. LINUX IN USER LEVEL 15 kernel enhancing the ptrace system call with useful functions for UML and an interface for address space manipulation in other address spaces via /proc/mm. Future versions of the patch will implement the functionality in other ways. Two new system calls will be introduced, one to create new address spaces and another to execute system calls in other contexts. It is likely that this patch will be merged with the main Linux kernel. The skas approach of UML has similarities to L 4 Linux. On both systems, the Linux kernel is located in its own address space. As the underlying systems are different, the implementations of both systems are done differently but conceptually they are similar FAUmachine The FAUmachine project [9] works on an open source virtual machine. The project evolved from the UMLinux project [5], a port of Linux to the Linux user mode, similar to UML discussed in the previous section. To reflect the focus from the pure Linux port towards a virtual machine, the project name was changed. FAUmachine works similarly to recent UML versions. The system is primarily used for fault injection to test the behavior of network applications [42] P4/Linux The SYSGO AG company is active in the field of small real-time systems as well as in the corresponding Linux area [46]. They have developed a V2 compatible L4 microkernel called P4 that runs on the x86, ARM [13] and PowerPC [39] architectures. On top of this kernel, a port of Linux 2.4 based on User Mode Linux was done. It is called P4/Linux [56]. Its design is similar to the traditional L 4 Linux design Other Approaches Running Linux as a user-space application is also possible by introducing a machine emulation layer. The Linux system itself does not need to be modified, although modifying Linux is possible to improve the performance in the virtualized system. VMware [51], Virtual PC [50], plex86 [37], z/vm [57] These systems provide virtual environments that can run various unmodified operating systems for the same hardware architecture as the host system, including Linux. Bochs [4], QEMU [38], SID [41], Simics [43] These programs provide machine emulators that can emulate various computer systems including some hardware components. The emulators itself can run on different architectures.
16 16 CHAPTER 2. FUNDAMENTALS AND RELATED WORK
17 Chapter 3 Design The goal of this work is to simplify the design of L 4 Linux by allowing modifications to the microkernel interface. This section will start with a short description of the design of past L 4 Linux versions, then explain what can be changed to simplify the design and how the microkernel and its interface must be modified to achieve this. 3.1 Traditional L 4 Linux design L 4 Linux-2.0 up to L 4 Linux-2.4 almost had the same design. The initial design of L 4 Linux is fully described in [21]. The system consists of a Linux task with several threads and a helper task as well as separate tasks for each user process. The server task uses several threads. The main thread executes the actual Linux code, called the Linux server. To handle interrupts one or more separate threads are needed, depending on the L4 version used. Another thread, called root pager, handles page faults of the Linux server. The Ping-Pong task is used to remap memory from the Linux server to the address space of the Linux server again. The tasks that handle user processes consist of two threads. The user thread executes the user program and the signal thread waits for commands from the Linux server to manipulate the user thread. An overview of the traditional design is depicted in Figure 3.1 on the following page The Linux Server The Linux server is the thread that executes the Linux kernel code. When the system is running, it is in the idle loop and waits to handle system calls, exceptions, and page faults of user processes Interrupts L4 translates interrupts into synchronous IPC notifications sent to the thread attached to the interrupt. With V2 and X.0 kernels a thread can attach to only one interrupt, making interrupt threads in L 4 Linux necessary. The X.2 interface supports multiple interrupts per thread. 17
18 18 CHAPTER 3. DESIGN Figure 3.1: Overview of the traditional L 4 Linux design On native Linux, interrupt work is always executed in the context of the interrupted user program, which is not possible in L 4 Linux as interrupt events are received in separate threads. Nevertheless, interrupt handlers that run on interrupt events execute Linux kernel code that expects a properly set up task structure on the stack. The stack of each interrupt thread is therefore initialized with the task structure of the idle process of Linux (also called swapper process). Hardware interrupts are prioritized, L 4 Linux emulates this behavior by giving interrupt threads different priorities. The priorities of all these threads are all different and higher than the priority of the Linux server. This way the behavior of hardware interrupts is emulated: an interrupt event interrupts the normal Linux server to handle top halves. L 4 Linux-2.2 and L 4 Linux-2.4 handle bottom halves slightly different. L 4 Linux-2.2 uses an extra L4 thread that is prioritized between the interrupt threads and the Linux server. L 4 Linux-2.4 uses the ksoftirqd Linux kernel thread for this, which is scheduled by the Linux scheduler and runs whenever deferred interrupt work needs to be done Signalling In native Linux, signals to user processes are handled after a system call or any other exception just before the user process returns to user mode. Signals can be easily delivered when the concerning task is chosen by the scheduler to continue execution. L 4 Linux has a different behavior in this regard. Logically, user processes can also run when the Linux server runs, that is, they are not blocked on the Linux server. Consequently, a user process could prevent to handle signals by not entering the Linux server, for example through system calls. A simple endless loop will suffice for this. To avoid this situation, the Linux server must be able to force a user process to enter the server. Currently, for security reasons the L4 interface does not allow to modify threads in other address spaces. To circumvent this restriction, the aforementioned signal thread comes into play. Using this thread, the Linux server can interrupt the user process by sending a message to the signal thread. The signal thread then forces the user process to execute special code to enter the Linux server.
19 3.1. TRADITIONAL L 4 LINUX DESIGN System-Call Emulation On the x86 architecture Linux programs use the interrupt gate 0x80 to enter the kernel and execute a system call. On L4 systems the corresponding instruction will cause an exception and the causing program will be terminated unless it installs an exception handler. V2 and X.0 kernels allow thread local exception handling only, making it necessary that the Linux server maps emulation code into the address space of each user process. This code is called whenever the execution of an int $0x80 instruction is detected. The emulation code needs to save the processor state of the process into a memory region shared with the Linux server and enter it by sending a blocking IPC of the type system call. Upon returning to the user process the emulation code needs to properly set up the processor state with the possibly updated values again. The X.2 specification of L4 offers the possibility to report exceptions to a designated thread, called exception handler, accompanied by the processor state of the faulting thread in an exception message. This mechanism allows to drop the system call related code from the emulation library and avoids one kernel entry. Another possibility to execute system calls on L 4 Linux is to modify the system-call code that the user programs use. For most programs this code is located in the C library to which the programs are dynamically linked. Instead of using the int $0x80 instruction they directly use the IPC call in the emulation code avoiding the exception Scheduling In an L 4 Linux system two schedulers are active. One is in the L4 kernel scheduling all L4 threads including L 4 Linux processes. The L4 scheduler uses static priorities and schedules threads with the same priority round-robin. The other scheduler is in the Linux server, deciding which Linux process to run next. L 4 Linux is designed in a way that from the view of the Linux server multiple user processes can be running in the L4 system. Furthermore, the Linux scheduler can only consider those processes that are blocked in the server. Consequently, the Linux server needs to distinguish between user processes being served by the Linux server and the ones running Memory Upon a page fault of a user process, L 4 Linux has to map memory into the address space of the requesting process using the L4 map and unmap operations. The Linux server manages all the memory for the L 4 Linux system and maps pages to user processes. All memory that user processes receive comes from the Linux server. L 4 Linux also manages shadow page tables as it does not have access to the real hardware page tables but nevertheless needs to manage page attributes to be able to properly map and unmap pages of user processes. L 4 Linux-2.4 uses an optimization during task deletion. If an address space is destroyed by the kernel, all mappings are deallocated as well. This allows to avoid the explicit address space deletion done by Linux before destroying a process, which otherwise imposes an avoidable overhead. Furthermore it has the positive side effect of not unmapping shared pages in other address spaces Time Accounting The Linux server needs to account the time of every user process in the system. Native Linux accomplishes this by updating the counters during each timer interrupt for the
20 20 CHAPTER 3. DESIGN context in which the handler runs. In L 4 Linux, interrupts including the timer interrupt run in separate threads and not in the (kernel) context of the currently executing user process. This can be circumvented by saving the last scheduled user process and adapting the corresponding parts of the generic timer handling code. Another problem is the inaccuracy of this scheme due to the design of L 4 Linux. A process executing an endless loop without entering the Linux server will not be accounted anymore if another process is scheduled inbetween which will likely happen. The fact that multiple user processes can be dispatched simultaneously is the main problem here Linux Threads Linux can run several processes in the same address space, usually referred to as Linux threads. L 4 Linux does not make use of this and puts every Linux process in a new address space even if they could share one. Implementing additional threads in an address space of a user process requires several modifications in the area of the code that is mapped in each user process as well as in the Linux server Summary The previous sections gave an overview on the traditional L 4 Linux design. With new mechanisms several parts of L 4 Linux can be made easier or even abolished. One point is the signal thread and the code that is mapped into each user process. The code exists because the corresponding L4 primitive to modify a thread cannot be used across address space boundaries. This restriction can easily be relaxed. Another area for improvements is the scheduling. The current scheduling shows bad results when CPU bound processes are run, making the system sluggish. 3.2 Microkernel Modifications When changing the microkernel and its interface to user programs we want to obey the rule that the behavior for existing programs is not changed, that is modifications must not change the semantics of existing functions. New mechanisms must be implemented by adding functionality. This approach assures that all existing programs keep working while programs aware of the new functionality can use it by either just accessing it or by switching the kernel to a new behavior for the context of the calling task. The platform this work is done on is the DROPS system, which currently means Fiasco with the Version 2 interface and the x86 architecture Ex-Regs Across Tasks L 4 Linux needs to handle signals for user processes. As described in Section on page 18, a signal thread in each user process address space is used to force the process to enter the Linux server as this cannot be initiated from outside of this user address space. Consequently the first step is to allow the l4_thread_ex_regs system call to work across address space boundaries. Of course, it cannot be allowed that an arbitrary thread is able to modify any other thread or create new threads in other address spaces at its own will. Neither the current L4 interface nor any implementation offer a mechanism which would allow to control the use of this system call. An example mechanism would be thread capabilities,
x86 ISA Modifications to support Virtual Machines
x86 ISA Modifications to support Virtual Machines Douglas Beal Ashish Kumar Gupta CSE 548 Project Outline of the talk Review of Virtual Machines What complicates Virtualization Technique for Virtualization
Last Class: OS and Computer Architecture. Last Class: OS and Computer Architecture
Last Class: OS and Computer Architecture System bus Network card CPU, memory, I/O devices, network card, system bus Lecture 3, page 1 Last Class: OS and Computer Architecture OS Service Protection Interrupts
Microkernels, virtualization, exokernels. Tutorial 1 CSC469
Microkernels, virtualization, exokernels Tutorial 1 CSC469 Monolithic kernel vs Microkernel Monolithic OS kernel Application VFS System call User mode What was the main idea? What were the problems? IPC,
How do Users and Processes interact with the Operating System? Services for Processes. OS Structure with Services. Services for the OS Itself
How do Users and Processes interact with the Operating System? Users interact indirectly through a collection of system programs that make up the operating system interface. The interface could be: A GUI,
An Implementation Of Multiprocessor Linux
An Implementation Of Multiprocessor Linux This document describes the implementation of a simple SMP Linux kernel extension and how to use this to develop SMP Linux kernels for architectures other than
Chapter 2: OS Overview
Chapter 2: OS Overview CmSc 335 Operating Systems 1. Operating system objectives and functions Operating systems control and support the usage of computer systems. a. usage users of a computer system:
The Microsoft Windows Hypervisor High Level Architecture
The Microsoft Windows Hypervisor High Level Architecture September 21, 2007 Abstract The Microsoft Windows hypervisor brings new virtualization capabilities to the Windows Server operating system. Its
VMware and CPU Virtualization Technology. Jack Lo Sr. Director, R&D
ware and CPU Virtualization Technology Jack Lo Sr. Director, R&D This presentation may contain ware confidential information. Copyright 2005 ware, Inc. All rights reserved. All other marks and names mentioned
10.04.2008. Thomas Fahrig Senior Developer Hypervisor Team. Hypervisor Architecture Terminology Goals Basics Details
Thomas Fahrig Senior Developer Hypervisor Team Hypervisor Architecture Terminology Goals Basics Details Scheduling Interval External Interrupt Handling Reserves, Weights and Caps Context Switch Waiting
Virtualization. Explain how today s virtualization movement is actually a reinvention
Virtualization Learning Objectives Explain how today s virtualization movement is actually a reinvention of the past. Explain how virtualization works. Discuss the technical challenges to virtualization.
Chapter 6, The Operating System Machine Level
Chapter 6, The Operating System Machine Level 6.1 Virtual Memory 6.2 Virtual I/O Instructions 6.3 Virtual Instructions For Parallel Processing 6.4 Example Operating Systems 6.5 Summary Virtual Memory General
CSE 120 Principles of Operating Systems. Modules, Interfaces, Structure
CSE 120 Principles of Operating Systems Fall 2000 Lecture 3: Operating System Modules, Interfaces, and Structure Geoffrey M. Voelker Modules, Interfaces, Structure We roughly defined an OS as the layer
evm Virtualization Platform for Windows
B A C K G R O U N D E R evm Virtualization Platform for Windows Host your Embedded OS and Windows on a Single Hardware Platform using Intel Virtualization Technology April, 2008 TenAsys Corporation 1400
VMkit A lightweight hypervisor library for Barrelfish
Masters Thesis VMkit A lightweight hypervisor library for Barrelfish by Raffaele Sandrini Due date 2 September 2009 Advisors: Simon Peter, Andrew Baumann, and Timothy Roscoe ETH Zurich, Systems Group Department
COS 318: Operating Systems. Virtual Machine Monitors
COS 318: Operating Systems Virtual Machine Monitors Kai Li and Andy Bavier Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall13/cos318/ Introduction u Have
Last Class: Introduction to Operating Systems. Today: OS and Computer Architecture
Last Class: Introduction to Operating Systems User apps OS Virtual machine interface hardware physical machine interface An operating system is the interface between the user and the architecture. History
Operating Systems 4 th Class
Operating Systems 4 th Class Lecture 1 Operating Systems Operating systems are essential part of any computer system. Therefore, a course in operating systems is an essential part of any computer science
Review from last time. CS 537 Lecture 3 OS Structure. OS structure. What you should learn from this lecture
Review from last time CS 537 Lecture 3 OS Structure What HW structures are used by the OS? What is a system call? Michael Swift Remzi Arpaci-Dussea, Michael Swift 1 Remzi Arpaci-Dussea, Michael Swift 2
Full and Para Virtualization
Full and Para Virtualization Dr. Sanjay P. Ahuja, Ph.D. 2010-14 FIS Distinguished Professor of Computer Science School of Computing, UNF x86 Hardware Virtualization The x86 architecture offers four levels
Virtualization for Cloud Computing
Virtualization for Cloud Computing Dr. Sanjay P. Ahuja, Ph.D. 2010-14 FIS Distinguished Professor of Computer Science School of Computing, UNF CLOUD COMPUTING On demand provision of computational resources
Uses for Virtual Machines. Virtual Machines. There are several uses for virtual machines:
Virtual Machines Uses for Virtual Machines Virtual machine technology, often just called virtualization, makes one computer behave as several computers by sharing the resources of a single computer between
Introduction. What is an Operating System?
Introduction What is an Operating System? 1 What is an Operating System? 2 Why is an Operating System Needed? 3 How Did They Develop? Historical Approach Affect of Architecture 4 Efficient Utilization
µ-kernels Advantages Primitives in a µ-kernel Disadvantages
µ-kernels Advantages The idea of µ-kernel is to minimize the kernel. I.e. to implement outside the kernel whatever possible. The µ-kernel concept is very old: Brinch Hansen s (1970) and Hydra (1974) Fault
Tools Page 1 of 13 ON PROGRAM TRANSLATION. A priori, we have two translation mechanisms available:
Tools Page 1 of 13 ON PROGRAM TRANSLATION A priori, we have two translation mechanisms available: Interpretation Compilation On interpretation: Statements are translated one at a time and executed immediately.
Virtualization. Pradipta De pradipta.de@sunykorea.ac.kr
Virtualization Pradipta De pradipta.de@sunykorea.ac.kr Today s Topic Virtualization Basics System Virtualization Techniques CSE506: Ext Filesystem 2 Virtualization? A virtual machine (VM) is an emulation
Kernel Types System Calls. Operating Systems. Autumn 2013 CS4023
Operating Systems Autumn 2013 Outline 1 2 Types of 2.4, SGG The OS Kernel The kernel is the central component of an OS It has complete control over everything that occurs in the system Kernel overview
Process Description and Control. 2004-2008 william stallings, maurizio pizzonia - sistemi operativi
Process Description and Control 1 Process A program in execution (running) on a computer The entity that can be assigned to and executed on a processor A unit of activity characterized by a at least one
Virtualization. Jukka K. Nurminen 23.9.2015
Virtualization Jukka K. Nurminen 23.9.2015 Virtualization Virtualization refers to the act of creating a virtual (rather than actual) version of something, including virtual computer hardware platforms,
COS 318: Operating Systems. Virtual Machine Monitors
COS 318: Operating Systems Virtual Machine Monitors Andy Bavier Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall10/cos318/ Introduction Have been around
White Paper. Real-time Capabilities for Linux SGI REACT Real-Time for Linux
White Paper Real-time Capabilities for Linux SGI REACT Real-Time for Linux Abstract This white paper describes the real-time capabilities provided by SGI REACT Real-Time for Linux. software. REACT enables
Kernel comparison of OpenSolaris, Windows Vista and. Linux 2.6
Kernel comparison of OpenSolaris, Windows Vista and Linux 2.6 The idea of writing this paper is evoked by Max Bruning's view on Solaris, BSD and Linux. The comparison of advantages and disadvantages among
Last Class: OS and Computer Architecture. Last Class: OS and Computer Architecture
Last Class: OS and Computer Architecture System bus Network card CPU, memory, I/O devices, network card, system bus Lecture 3, page 1 Last Class: OS and Computer Architecture OS Service Protection Interrupts
Performance Comparison of RTOS
Performance Comparison of RTOS Shahmil Merchant, Kalpen Dedhia Dept Of Computer Science. Columbia University Abstract: Embedded systems are becoming an integral part of commercial products today. Mobile
SYSTEM ecos Embedded Configurable Operating System
BELONGS TO THE CYGNUS SOLUTIONS founded about 1989 initiative connected with an idea of free software ( commercial support for the free software ). Recently merged with RedHat. CYGNUS was also the original
Introduction to Operating Systems. Perspective of the Computer. System Software. Indiana University Chen Yu
Introduction to Operating Systems Indiana University Chen Yu Perspective of the Computer System Software A general piece of software with common functionalities that support many applications. Example:
Virtual Hosting & Virtual Machines
& Virtual Machines Coleman Kane Coleman.Kane@ge.com September 2, 2014 Cyber Defense Overview / Machines 1 / 17 Similar to the network partitioning schemes described previously, there exist a menu of options
Chapter 3: Operating-System Structures. System Components Operating System Services System Calls System Programs System Structure Virtual Machines
Chapter 3: Operating-System Structures System Components Operating System Services System Calls System Programs System Structure Virtual Machines Operating System Concepts 3.1 Common System Components
COS 318: Operating Systems
COS 318: Operating Systems OS Structures and System Calls Andy Bavier Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall10/cos318/ Outline Protection mechanisms
Virtual Machine Monitors. Dr. Marc E. Fiuczynski Research Scholar Princeton University
Virtual Machine Monitors Dr. Marc E. Fiuczynski Research Scholar Princeton University Introduction Have been around since 1960 s on mainframes used for multitasking Good example VM/370 Have resurfaced
Chapter 3 Operating-System Structures
Contents 1. Introduction 2. Computer-System Structures 3. Operating-System Structures 4. Processes 5. Threads 6. CPU Scheduling 7. Process Synchronization 8. Deadlocks 9. Memory Management 10. Virtual
Virtual machines and operating systems
V i r t u a l m a c h i n e s a n d o p e r a t i n g s y s t e m s Virtual machines and operating systems Krzysztof Lichota lichota@mimuw.edu.pl A g e n d a Virtual machines and operating systems interactions
Chapter 2 Operating System Overview
Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 2 Operating System Overview Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Roadmap Operating System Objectives/Functions
FRONT FLYLEAF PAGE. This page has been intentionally left blank
FRONT FLYLEAF PAGE This page has been intentionally left blank Abstract The research performed under this publication will combine virtualization technology with current kernel debugging techniques to
Virtual Private Systems for FreeBSD
Virtual Private Systems for FreeBSD Klaus P. Ohrhallinger 06. June 2010 Abstract Virtual Private Systems for FreeBSD (VPS) is a novel virtualization implementation which is based on the operating system
Hypervisors and Virtual Machines
Hypervisors and Virtual Machines Implementation Insights on the x86 Architecture DON REVELLE Don is a performance engineer and Linux systems/kernel programmer, specializing in high-volume UNIX, Web, virtualization,
CPS221 Lecture: Operating System Structure; Virtual Machines
Objectives CPS221 Lecture: Operating System Structure; Virtual Machines 1. To discuss various ways of structuring the operating system proper 2. To discuss virtual machines Materials: 1. Projectable of
CS 377: Operating Systems. Outline. A review of what you ve learned, and how it applies to a real operating system. Lecture 25 - Linux Case Study
CS 377: Operating Systems Lecture 25 - Linux Case Study Guest Lecturer: Tim Wood Outline Linux History Design Principles System Overview Process Scheduling Memory Management File Systems A review of what
KVM: Kernel-based Virtualization Driver
KVM: Kernel-based Virtualization Driver White Paper Overview The current interest in virtualization has led to the creation of several different hypervisors. Most of these, however, predate hardware-assisted
Hypervisors. Introduction. Introduction. Introduction. Introduction. Introduction. Credits:
Hypervisors Credits: P. Chaganti Xen Virtualization A practical handbook D. Chisnall The definitive guide to Xen Hypervisor G. Kesden Lect. 25 CS 15-440 G. Heiser UNSW/NICTA/OKL Virtualization is a technique
Example of Standard API
16 Example of Standard API System Call Implementation Typically, a number associated with each system call System call interface maintains a table indexed according to these numbers The system call interface
Operating System Structures
Operating System Structures Meelis ROOS mroos@ut.ee Institute of Computer Science Tartu University fall 2009 Literature A. S. Tanenbaum. Modern Operating Systems. 2nd ed. Prentice Hall. 2001. G. Nutt.
III. Process Scheduling
Intended Schedule III. Process Scheduling Date Lecture Hand out Submission 0 20.04. Introduction to Operating Systems Course registration 1 27.04. Systems Programming using C (File Subsystem) 1. Assignment
III. Process Scheduling
III. Process Scheduling 1 Intended Schedule Date Lecture Hand out Submission 0 20.04. Introduction to Operating Systems Course registration 1 27.04. Systems Programming using C (File Subsystem) 1. Assignment
VMware Server 2.0 Essentials. Virtualization Deployment and Management
VMware Server 2.0 Essentials Virtualization Deployment and Management . This PDF is provided for personal use only. Unauthorized use, reproduction and/or distribution strictly prohibited. All rights reserved.
OpenMosix Presented by Dr. Moshe Bar and MAASK [01]
OpenMosix Presented by Dr. Moshe Bar and MAASK [01] openmosix is a kernel extension for single-system image clustering. openmosix [24] is a tool for a Unix-like kernel, such as Linux, consisting of adaptive
Virtualization. P. A. Wilsey. The text highlighted in green in these slides contain external hyperlinks. 1 / 16
Virtualization P. A. Wilsey The text highlighted in green in these slides contain external hyperlinks. 1 / 16 Conventional System Viewed as Layers This illustration is a common presentation of the application/operating
ELEC 377. Operating Systems. Week 1 Class 3
Operating Systems Week 1 Class 3 Last Class! Computer System Structure, Controllers! Interrupts & Traps! I/O structure and device queues.! Storage Structure & Caching! Hardware Protection! Dual Mode Operation
What is a Thread? Similar to a process Separate thread of execution Each thread has a separate stack, program counter, and run state
What is a Thread? Similar to a process Separate thread of execution Each thread has a separate stack, program counter, and run state Steven M. Bellovin February 1, 2006 1 Differences Between Processes
Virtual Machines. www.viplavkambli.com
1 Virtual Machines A virtual machine (VM) is a "completely isolated guest operating system installation within a normal host operating system". Modern virtual machines are implemented with either software
Virtualization. Types of Interfaces
Virtualization Virtualization: extend or replace an existing interface to mimic the behavior of another system. Introduced in 1970s: run legacy software on newer mainframe hardware Handle platform diversity
Multi-core Programming System Overview
Multi-core Programming System Overview Based on slides from Intel Software College and Multi-Core Programming increasing performance through software multi-threading by Shameem Akhter and Jason Roberts,
Project No. 2: Process Scheduling in Linux Submission due: April 28, 2014, 11:59pm
Project No. 2: Process Scheduling in Linux Submission due: April 28, 2014, 11:59pm PURPOSE Getting familiar with the Linux kernel source code. Understanding process scheduling and how different parameters
Operating Systems Concepts: Chapter 7: Scheduling Strategies
Operating Systems Concepts: Chapter 7: Scheduling Strategies Olav Beckmann Huxley 449 http://www.doc.ic.ac.uk/~ob3 Acknowledgements: There are lots. See end of Chapter 1. Home Page for the course: http://www.doc.ic.ac.uk/~ob3/teaching/operatingsystemsconcepts/
Operating Systems Design 23. Virtualization
Operating Systems Design 23. Virtualization Paul Krzyzanowski pxk@cs.rutgers.edu 1 Virtualization Memory virtualization Process feels like it has its own address space Created by MMU, configured by OS
Lesson Objectives. To provide a grand tour of the major operating systems components To provide coverage of basic computer system organization
Lesson Objectives To provide a grand tour of the major operating systems components To provide coverage of basic computer system organization AE3B33OSD Lesson 1 / Page 2 What is an Operating System? A
Chapter 3: Operating-System Structures. Common System Components
Chapter 3: Operating-System Structures System Components Operating System Services System Calls System Programs System Structure Virtual Machines System Design and Implementation System Generation 3.1
Performance and Implementation Complexity in Multiprocessor Operating System Kernels
Performance and Implementation Complexity in Multiprocessor Operating System Kernels Simon Kågström Department of Systems and Software Engineering Blekinge Institute of Technology Ronneby, Sweden http://www.ipd.bth.se/ska
Operating System Components
Lecture Overview Operating system software introduction OS components OS services OS structure Operating Systems - April 24, 2001 Operating System Components Process management Memory management Secondary
Virtualization. P. A. Wilsey. The text highlighted in green in these slides contain external hyperlinks. 1 / 16
1 / 16 Virtualization P. A. Wilsey The text highlighted in green in these slides contain external hyperlinks. 2 / 16 Conventional System Viewed as Layers This illustration is a common presentation of the
CS161: Operating Systems
CS161: Operating Systems Matt Welsh mdw@eecs.harvard.edu Lecture 2: OS Structure and System Calls February 6, 2007 1 Lecture Overview Protection Boundaries and Privilege Levels What makes the kernel different
Introduction to Virtual Machines
Introduction to Virtual Machines Introduction Abstraction and interfaces Virtualization Computer system architecture Process virtual machines System virtual machines 1 Abstraction Mechanism to manage complexity
Software Security. Memory Virtualization. Jan Nordholz. Prof. Jean-Pierre Seifert Security in Telecommunications TU Berlin.
Software Security Memory Virtualization Jan Nordholz Prof. Jean-Pierre Seifert Security in Telecommunications TU Berlin SoSe 2016 jan (sect) Software Security SoSe 2016 1 / 27 Virtualization (Recap) assume
Lecture 25 Symbian OS
CS 423 Operating Systems Design Lecture 25 Symbian OS Klara Nahrstedt Fall 2011 Based on slides from Andrew S. Tanenbaum textbook and other web-material (see acknowledgements) cs423 Fall 2011 1 Overview
Virtualization in Linux KVM + QEMU
CS695 Topics in Virtualization and Cloud Computing KVM + QEMU Senthil, Puru, Prateek and Shashank 1 Topics covered KVM and QEMU Architecture VTx support CPU virtualization in KMV Memory virtualization
Real-Time Systems Prof. Dr. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur
Real-Time Systems Prof. Dr. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture No. # 26 Real - Time POSIX. (Contd.) Ok Good morning, so let us get
The Xen of Virtualization
The Xen of Virtualization Assignment for CLC-MIRI Amin Khan Universitat Politècnica de Catalunya March 4, 2013 Amin Khan (UPC) Xen Hypervisor March 4, 2013 1 / 19 Outline 1 Introduction 2 Architecture
Operating Systems (OS)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Operating Systems (OS) An operating system defines an abstraction of hardware and manages resource sharing among the computer s users. The topics in this area explain the
Chapter 5 Cloud Resource Virtualization
Chapter 5 Cloud Resource Virtualization Contents Virtualization. Layering and virtualization. Virtual machine monitor. Virtual machine. Performance and security isolation. Architectural support for virtualization.
(Advanced Topics in) Operating Systems Winter Term 2009 / 2010. Jun.-Prof. Dr.-Ing. André Brinkmann brinkman@upb.de Universität Paderborn PC
(Advanced Topics in) Operating Systems Winter Term 2009 / 2010 Jun.-Prof. Dr.-Ing. André Brinkmann brinkman@upb.de Universität Paderborn PC 1 Overview Overview of chapter 3: Case Studies 3.1 Windows Architecture.....3
Processes and Non-Preemptive Scheduling. Otto J. Anshus
Processes and Non-Preemptive Scheduling Otto J. Anshus 1 Concurrency and Process Challenge: Physical reality is Concurrent Smart to do concurrent software instead of sequential? At least we want to have
Security Overview of the Integrity Virtual Machines Architecture
Security Overview of the Integrity Virtual Machines Architecture Introduction... 2 Integrity Virtual Machines Architecture... 2 Virtual Machine Host System... 2 Virtual Machine Control... 2 Scheduling
RTAI. Antonio Barbalace antonio.barbalace@unipd.it. (modified by M.Moro 2011) RTAI
Antonio Barbalace antonio.barbalace@unipd.it (modified by M.Moro 2011) Real Time Application Interface by Dipartimento di Ingegneria Aereospaziale dell Università di Milano (DIAPM) It is not a complete
Jukka Ylitalo Tik-79.5401 TKK, April 24, 2006
Rich Uhlig, et.al, Intel Virtualization Technology, Computer, published by the IEEE Computer Society, Volume 38, Issue 5, May 2005. Pages 48 56. Jukka Ylitalo Tik-79.5401 TKK, April 24, 2006 Outline of
KVM: A Hypervisor for All Seasons. Avi Kivity avi@qumranet.com
KVM: A Hypervisor for All Seasons Avi Kivity avi@qumranet.com November 2007 Virtualization Simulation of computer system in software Components Processor: register state, instructions, exceptions Memory
COS 318: Operating Systems. CPU Scheduling. (http://www.cs.princeton.edu/courses/cos318/)
COS 318: Operating Systems CPU Scheduling (http://www.cs.princeton.edu/courses/cos318/) Today s Topics! CPU scheduling! CPU Scheduling algorithms 2 When to Schedule?! Process/thread creation! Process/thread
Operating System Structures
COP 4610: Introduction to Operating Systems (Spring 2015) Operating System Structures Zhi Wang Florida State University Content Operating system services User interface System calls System programs Operating
Ada Real-Time Services and Virtualization
Ada Real-Time Services and Virtualization Juan Zamorano, Ángel Esquinas, Juan A. de la Puente Universidad Politécnica de Madrid, Spain jzamora,aesquina@datsi.fi.upm.es, jpuente@dit.upm.es Abstract Virtualization
Overview of Operating Systems Instructor: Dr. Tongping Liu
Overview of Operating Systems Instructor: Dr. Tongping Liu Thank Dr. Dakai Zhu and Dr. Palden Lama for providing their slides. 1 Lecture Outline Operating System: what is it? Evolution of Computer Systems
Chapter 2 System Structures
Chapter 2 System Structures Operating-System Structures Goals: Provide a way to understand an operating systems Services Interface System Components The type of system desired is the basis for choices
Basics of Virtualisation
Basics of Virtualisation Volker Büge Institut für Experimentelle Kernphysik Universität Karlsruhe Die Kooperation von The x86 Architecture Why do we need virtualisation? x86 based operating systems are
VxWorks Guest OS Programmer's Guide for Hypervisor 1.1, 6.8. VxWorks GUEST OS PROGRAMMER'S GUIDE FOR HYPERVISOR 1.1 6.8
VxWorks Guest OS Programmer's Guide for Hypervisor 1.1, 6.8 VxWorks GUEST OS PROGRAMMER'S GUIDE FOR HYPERVISOR 1.1 6.8 Copyright 2009 Wind River Systems, Inc. All rights reserved. No part of this publication
Technical Properties. Mobile Operating Systems. Overview Concepts of Mobile. Functions Processes. Lecture 11. Memory Management.
Overview Concepts of Mobile Operating Systems Lecture 11 Concepts of Mobile Operating Systems Mobile Business I (WS 2007/08) Prof Dr Kai Rannenberg Chair of Mobile Business and Multilateral Security Johann
Virtualization Technologies (ENCS 691K Chapter 3)
Virtualization Technologies (ENCS 691K Chapter 3) Roch Glitho, PhD Associate Professor and Canada Research Chair My URL - http://users.encs.concordia.ca/~glitho/ The Key Technologies on Which Cloud Computing
Windows8 Internals, Sixth Edition, Part 1
Microsoft Windows8 Internals, Sixth Edition, Part 1 Mark Russinovich David A. Solomon Alex lonescu Windows Internals, Sixth Edition, Part i Introduction xvii Chapter 1 Concepts and Tools 1 Windows Operating
Architecture of the Kernel-based Virtual Machine (KVM)
Corporate Technology Architecture of the Kernel-based Virtual Machine (KVM) Jan Kiszka, Siemens AG, CT T DE IT 1 Corporate Competence Center Embedded Linux jan.kiszka@siemens.com Copyright Siemens AG 2010.
Operating Systems, 6 th ed. Test Bank Chapter 7
True / False Questions: Chapter 7 Memory Management 1. T / F In a multiprogramming system, main memory is divided into multiple sections: one for the operating system (resident monitor, kernel) and one
Virtualization of Linux based computers: the Linux-VServer project
Virtualization of Linux based computers: the Linux-VServer project Benoît t des Ligneris, Ph. D. Benoit.des.Ligneris@RevolutionLinux.com Objectives: Objectives: 1) Present the available programs that can
kvm: Kernel-based Virtual Machine for Linux
kvm: Kernel-based Virtual Machine for Linux 1 Company Overview Founded 2005 A Delaware corporation Locations US Office Santa Clara, CA R&D - Netanya/Poleg Funding Expertise in enterprise infrastructure
6.828 Operating System Engineering: Fall 2003. Quiz II Solutions THIS IS AN OPEN BOOK, OPEN NOTES QUIZ.
Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY 6.828 Operating System Engineering: Fall 2003 Quiz II Solutions All problems are open-ended questions. In
Real-Time Scheduling 1 / 39
Real-Time Scheduling 1 / 39 Multiple Real-Time Processes A runs every 30 msec; each time it needs 10 msec of CPU time B runs 25 times/sec for 15 msec C runs 20 times/sec for 5 msec For our equation, A