DOCSLIB.ORG

Virtual Processors As Kernel Interface

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Virtual Processors As Kernel Interface Virtual Processors as Kernel Interface Adam Lackorzynski, Alexander Warg Michael Peter Technische Universit¨at Dresden Technische Universit¨at Berlin Department of Computer Science Deutsche Telekom Laboratories Operating Systems Group Security in Telecommunications {adam, warg}@os.inf.tu-dresden.de [email protected] Abstract After virtualization has gained traction in a variety of fields ranging from the desktop computer to datacenter servers, it is likely to make inroads into embedded systems as well. The complexity of a VM implementation depends on the virtualization abilities of the processor used. Unfortunately, the instruction set architecture of many popular embedded CPUs is not virtualizable, which precludes efficient pure or faithful virtualization. In this paper, we make the case for operating system (OS) rehosting, a flavor of virtualization that lends itself to implementations of low complexity and does not rely an CPU virtualization extensions. The feasibility of OS rehosting crucially depends on the traits of the interface of the underlying kernel. Our observation was that the ubiquitously used thread model is rather poorly suited to run an OS on top. As a solution, we propose the currently often employed threads be supplemented with virtual processors (vCPUs), an abstraction that is more aligned with the underlying hardware. To evaluate our proposition, we ported the Linux kernel to a vCPU enhanced version of the Fiasco microkernel. Compared to a previous thread-based version, the vCPU version required much less devel- opment effort. The performance gains range from slight to well-pronounced depending on the workload. 1 Introduction codes protected. The network operator is concerned about stable network operations. Content providers insist on the enforcement of the consumption rules The market for embedded devices has undergone a for their content. Unfortunately, current systems fundamental transition in the recent past. Closed have inherent design and implementation flaws that special purpose devices with a fairly limited re- prevent them from isolating multiple stakeholders on source budget have turned into general purpose gad- one machine reliably. The underlying reason is the gets that often exhibit performance characteristics lack of mechanisms to grant authority selectively fol- of desktop machines of a couple of years ago. Such lowing the principle of least authority. There are too rapid strides in capabilities led to calls for new fea- many parts of the system that run with privileges tures, foremost the ability to customize devices by sufficient to take over the whole system if subverted. installing software according to personal preferences. Microkernels have shown that they can con- However, the record of operating systems in the last tribute to making the trustworthiness problem more years does not instill confidence when it comes to tractable. Their contribution is twofold: first, they security. What is a nuisance on desktop systems, be- allow for the construction of systems with very small comes an unacceptable risk for some embedded sys- trusted computing bases (TCB). That is achieved by tems. For example, no network operator can tolerate minimizing the amount of code running in the most smartphones that came under illegitimate control af- privileged execution mode, where it is, by definition, ter a downloaded application subverted the handset part of the trusted computing base of any applica- and turned it into a jammer. tion regardless of whether the code is actually needed The situation is complicated by the presence by an application. In contrast, functionality resident of multiple parties who want their interests safe- in user-level tasks can only affect other applications guarded. The owner wants his assets such as access if it was explicitly granted sufficient authority. 1 Second, not subject to backward compatibility whereby operating systems run on a machine with- requirements, microkernels can break new grounds out exercising absolute control over it. In that mean- regarding security features. A huge step for- ing it is left open whether the guest OS is modified ward was the adoption of capability-based security and, if so, how intrusive that modification is. Apart schemes [19][12]. Facilitating the principle of least from (faithful or pure) virtualization, paravirtualiza- authority, capabilities are regarded as superior to tion and OS rehosting are possible. access-control lists based systems [16]. In a stricter sense, virtualization denotes a Their individual shortcomings notwithstanding, method whereby software is provided with an envi- operating systems are valuable components that no ronment that is a genuine replica of a physical ma- non-trivial system can dispense with. Economic chine. If used in that context, it contrasts with par- pressure mandates the deployment of existing sys- avirtualization and OS rehosting as the two latter tems as no single organisation can hope for devel- provide environments that only resemble a physical oping a reasonable OS in an acceptable time frame. machine. Accordingly, virtualization is, in principle, Virtualization allows leveraging their strengths while compatible with all operating systems whereas par- still enforcing isolation thereby limiting the poten- avirtualization and OS rehosting require more or less tially affected scope in case of a failure or subversion. intrusive changes. Figure 1 illustrates the different virtualization approaches, which we will describe in Commodity processors in desktop and server sys- more details in the following sections. tems feature to a large extent virtualization exten- sions, which are missing from most embedded pro- a) OS OS cessors. Yet, previous work[9] has shown that small OS b) kernels can encapsulate operating systems on com- Hypervisor/VMM modity processors that do not efficiently support vir- Hardware tualization. No virtualization Hardware Full Virtualization For reasons that are partly historical, microker- nel designs paid more attention to raw message pass- c) OS OS d) OS OS ing performance than to the ease of OS rehosting. Hypervisor/VMM In this paper, we propose to augment the kernel in- Hypervisor/VMM terface with virtual CPUs, an execution abstraction Hardware Hardware that bears a close resemblance to physical CPUs. Paravirtualization This addition to the kernel interface has the poten- OS Rehosting tial to reduce the porting effort while increasing the OS API HW Interface confidence in the correctness of the changes to the HW Interface with problematic guest operating system. instructions replaced with Hypervisor calls 1.1 Outline FIGURE 1: Overview over different vir- tualization approaches. Virtualization dupli- We will proceed with a discussion of what the choices cates the machine interface with high fidelity, are regarding the implementation of the CPU part of whereas paravirtualization replaces problem- virtual machines (Section 2) before we detail the de- atic instructions with calls to the underlying sign of virtual CPUs in Section 3. To prove the feasi- kernel. OS rehosting goes further and provides bility of the proposition, we report on our implemen- a fairly abstracted kernel interface with many tation (Section 5) and describe how the Linux kernel implementation specifics left out. can be ported onto it (Section 6). Our conclusion (Section 9) is preceded by measurements (Section 7) 2.1 Faithful Virtualization that give an impression of the performance charac- teristics and related work (Section 8). Faithful virtualization – sometimes also referred to as pure or full virtualization – provides an environ- ment that is a genuine copy of a physical machine. 2 Virtualization That allows for an existing operating system to be deployed without any modifications. The term virtualization itself is used in two differ- However, despite its merits, virtualization did ent contexts which occasionally gives rise to confu- not catch on in the commodity market because com- sion. In a wider sense, virtualization is a technology modity processors did not have adequate support for 2 virtualization. For an instruction set architecture 2.3 OS Rehosting (ISA) to be virtualizable, it has to meet the Popek- Goldberg criterion[17]. Briefly, it mandates that Paravirtualization pays for the non-intrusive guest each sensitive instruction is also privileged. A sensi- changes with the introduction of complexity into the tive instruction is one that either reveals (privileged) kernel, which has to cover all quirks of a given ISA. 1 execution state or affects the execution . Many pop- That contrasts with OS rehosting, which aims to cap- ular ISAs, though, are not virtualizable with x86[18] ture only those features that are necessary to host an and ARM[6] the most prominent examples. operating system. The intention behind that change Although it is possible to implement faithful vir- is to simplify the implementation of the kernel by tualization on CPUs with non-virtualizable ISAs, do- deliberately dropping unused features that are of no ing so efficiently involves complex technologies such importance for modern operating systems. as binary translation[3][1]. As such, this approach The simplification of the kernel comes at the cost is of little appeal to security-concerned systems be- of more intrusive changes required for the guest OS. cause their trustworthiness is negatively affected by Depending on the used system, it is likely possi- complexity. ble that the features provided by the kernel such as threads or address
Load more

Recommended publications
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Run-Time Reconfigurable RTOS for Reconfigurable Systems-On-Chip
    Run-time Reconfigurable RTOS for Reconfigurable Systems-on-Chip Dissertation A thesis submited to the Faculty of Computer Science, Electrical Engineering and Mathematics of the University of Paderborn and to the Graduate Program in Electrical Engineering (PPGEE) of the Federal University of Rio Grande do Sul in partial fulfillment of the requirements for the degree of Dr. rer. nat. and Dr. in Electrical Engineering Marcelo G¨otz November, 2007 Supervisors: Prof. Dr. rer. nat. Franz J. Rammig, University of Paderborn, Germany Prof. Dr.-Ing. Carlos E. Pereira, Federal University of Rio Grande do Sul, Brazil Public examination in Paderborn, Germany Additional members of examination committee: Prof. Dr. Marco Platzner Prof. Dr. Urlich R¨uckert Dr. Mario Porrmann Date: April 23, 2007 Public examination in Porto Alegre, Brazil Additional members of examination committee: Prof. Dr. Fl´avioRech Wagner Prof. Dr. Luigi Carro Prof. Dr. Altamiro Amadeu Susin Prof. Dr. Leandro Buss Becker Prof. Dr. Fernando Gehm Moraes Date: October 11, 2007 Acknowledgements This PhD thesis was carried out, in his great majority, at the Department of Computer Science, Electrical Engineering and Mathematics of the University of Paderborn, during my time as a fellow of the working group of Prof. Dr. Franz J. Rammig. Due to a formal agreement between Federal University of Rio Grande do Sul (UFRGS) and University of Paderborn, I had the opportunity to receive a bi-national doctoral degree. Therefore, I had to accomplished, in addition, the PhD Graduate Program in Electrical Engineering of UFRGS. So, I hereby acknowledge, without mention everyone personally, all persons involved in making this agreement possible.
    [Show full text]
  • Introduction
    1 INTRODUCTION A modern computer consists of one or more processors, some main memory, disks, printers, a keyboard, a mouse, a display, network interfaces, and various other input/output devices. All in all, a complex system.oo If every application pro- grammer had to understand how all these things work in detail, no code would ever get written. Furthermore, managing all these components and using them optimally is an exceedingly challenging job. For this reason, computers are equipped with a layer of software called the operating system, whose job is to provide user pro- grams with a better, simpler, cleaner, model of the computer and to handle manag- ing all the resources just mentioned. Operating systems are the subject of this book. Most readers will have had some experience with an operating system such as Windows, Linux, FreeBSD, or OS X, but appearances can be deceiving. The pro- gram that users interact with, usually called the shell when it is text based and the GUI (Graphical User Interface)—which is pronounced ‘‘gooey’’—when it uses icons, is actually not part of the operating system, although it uses the operating system to get its work done. A simple overview of the main components under discussion here is given in Fig. 1-1. Here we see the hardware at the bottom. The hardware consists of chips, boards, disks, a keyboard, a monitor, and similar physical objects. On top of the hardware is the software. Most computers have two modes of operation: kernel mode and user mode. The operating system, the most fundamental piece of soft- ware, runs in kernel mode (also called supervisor mode).
    [Show full text]
  • Kernel Architectures
    A short history of kernels n Early kernel: a library of device drivers, support for threads (QNX) Operating System Kernels n Monolithic kernels: Unix, VMS, OS 360… n Unstructured but fast… n Over time, became very large Ken Birman n Eventually, DLLs helped on size n Pure microkernels: Mach, Amoeba, Chorus… (borrowing some content from n OS as a kind of application Peter Sirokman) n Impure microkernels: Modern Windows OS n Microkernel optimized to support a single OS n VMM support for Unix on Windows and vice versa The great m-kernel debate Summary of First Paper n How big does it need to be? n The Performance of µ-Kernel-Based Systems (Hartig et al. 16th SOSP, Oct 1997) n With a m-kernel protection-boundary crossing forces us to n Evaluates the L4 microkernel as a basis for a full operating system n Change memory -map n Ports Linux to run on top of L4 and compares n Flush TLB (unless tagged) performance to native Linux and Linux running on n With a macro-kernel we lose structural the Mach microkernel protection benefits and fault-containment n Explores the extensibility of the L4 microkernel n Debate raged during early 1980’s Summary of Second Paper In perspective? n The Flux OSKit: A Substrate for Kernel and n L4 seeks to validate idea that a m-kernel Language Research (Ford et al. 16th SOSP, can support a full OS without terrible 1997) cost penalty n Describes a set of OS components designed to be used to build custom operating systems n Opened the door to architectures like the n Includes existing code simply using “glue code” Windows
    [Show full text]
  • Microkernel Construction Introduction
    Microkernel Construction Introduction Nils Asmussen 04/06/2017 1 / 28 Outline Introduction Goals Administration Monolithic vs. Microkernel Overview About L4/NOVA 2 / 28 Goals 1 Provide deeper understanding of OS mechanisms 2 Look at the implementation details of microkernels 3 Make you become enthusiastic microkernel hackers 4 Propaganda for OS research at TU Dresden 3 / 28 Administration Thursday, 4th DS, 2 SWS Slides: www.tudos.org ! Teaching ! Microkernel Construction Subscribe to our mailing list: www.tudos.org/mailman/listinfo/mkc2017 In winter term: Microkernel-based operating systems (MOS) Various labs 4 / 28 Outline Introduction Monolithic vs. Microkernel Kernel design comparison Examples for microkernel-based systems Vision vs. Reality Challenges Overview About L4/NOVA 5 / 28 Monolithic Kernel System Design u s Application Application Application e r k Kernel e r File Network n e Systems Stacks l m Memory Process o Drivers Management Management d e Hardware 6 / 28 Monolithic Kernel OS (Propaganda) System components run in privileged mode No protection between system components Faulty driver can crash the whole system Malicious app could exploit bug in faulty driver More than 2=3 of today's OS code are drivers No need for good system design Direct access to data structures Undocumented and frequently changing interfaces Big and inflexible Difficult to replace system components Difficult to understand and maintain Why something different? ! Increasingly difficult to manage growing OS complexity 7 / 28 Microkernel System Design Application
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Analysis of Existing Dynamic Software Updating Techniques for Safe and Secure Industrial Control Systems
    I. Mugarza, et al., Int. J. of Safety and Security Eng., Vol. 8, No. 1 (2018) 121–131 ANALYSIS OF EXISTING DYNAMIC SOFTWARE UPDATING TECHNIQUES FOR SAFE AND SECURE INDUSTRIAL CONTROL SYSTEMS IMANOL MUGARZA1, JORGE PARRA1 & EDUARDO JACOB2 1 IK4-Ikerlan Technology Research Centre, Dependable Embedded Systems Area. 2 Faculty of Engineering, University of the Basque Country UPV/EHU. ABSTRACT Higher interconnectivity among devices, machines, the cloud and humans is envisioned in the actual trend of automation, also known as Industrial Internet of Things (IIoT). These industrial control systems, which may require high availability and/or safety related capabilities, are no longer isolated from the corporate environment or Internet. Software updates will be needed during the product life cycle, due to the long service life, the increasing number of security related vulnerabilities discovered on these industrial control systems and the high interconnectivity desired in IIoT. These updates aim at fixing all these security weaknesses, bugs and vulnerabilities that could appear, while the required safety integrity levels are ensured. Security-related concerns have just been addressed by the safety engineering community, because of the increasing number of cyber-attacks against safety-critical systems, such as Stuxnet. Moreover, system shut-downs caused by software updates could not be plausible when high availability is required. Typically, in order to perform the software update, the whole industrial process or the production is halted, so that the software upgrade is safely applied. However, this scenario might not be applied in critical infrastructures, such as nuclear or hydro- electrical power plants, where these production and service interruptions are not acceptable from the business and service point of view.
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]
  • Common Coupling As a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of Mklinux and Darwin
    IUScholarWorks at Indiana University South Bend Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin Yu, Liguo To cite this article: Yu, Liguo. “Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin.” Journal of the Brazilian Computer Society14, vol. 14, no. 1, Feb. 2008, pp. 45–55. This document has been made available through IUScholarWorks repository, a service of the Indiana University Libraries. Copyrights on documents in IUScholarWorks are held by their respective rights holder(s). Contact [email protected] for more information. Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin Liguo Yu Department of Informatics Computer and Information Sciences Department Indiana University South Bend South Bend, IN 46634, USA. Fax: 1-574-520-5589 E-mail: [email protected] The initial version of this paper appers in the 19th International Conference on Software Engineering and Knowledge Engineering. Abstract software components, which required less effort in order to be reused to produce Darwin. An obstacle to software reuse is the large number of major modifications that frequently have to be made Keywords: Reuse, common coupling, kernel-based software, as a consequence of dependencies within the reused MkLinux, Darwin software components. In this paper, common coupling is categorized and used as a measure of the dependencies 1. INTRODUCTION between software components. We compared common Software reuse has become a topic of interest within coupling in three operating systems, Linux, FreeBSD, the software community because of its potential and Mach, and related it to the reuse effort of these benefits.
    [Show full text]
  • Kernel-Based Systems
    The Performance of µ-Kernel-Based Systems Liedtke et al. presented by: Ryan O’Connor <[email protected]> October 7th, 2009 Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems Motivation By this time (1997) the OS research community had virtually abandoned research on pure µ-kernels. due primarily to the poor performance of first-generation µ-kernels Many researchers believe that µ-kernel abstraction layer is either too low or too high too low: research should focus on extensible-kernels, allowing users to safely add new functionality to a monolithic kernel too high: kernels should export an interface resembling a hardware architecture Claim: pure µ-kernels are not fundamentally flawed, they just haven’t been done right yet Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems Contributions L4 and L4Linux the penalty for using a pure µ-kernel can be kept between 5% and 10% µ-kernel abstractions are efficient enough to motivate their use in user applications Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems L4 L4 exports a pure µ-kernel interface (threads, address spaces, and IPC). In addition it supports: user-level paging, and recursive construction of address spaces translation of hardware interrupts to IPC messages fast context switches on small address-spaces using Pentium segmentation trick Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems L4Linux L4Linux is a Linux Single Server, an L4 process that provides a unix ’personality’ for user applications.
    [Show full text]
  • Popcorn Project: Starting with Popcorn OS
    Popcorn Project: Starting with Popcorn OS Antonio Barbalace [email protected] Systems Software Research Group at Virginia Tech http://ssrg.ece.vt.edu VTLUUG meeting , May 2 nd 2013 Patches 14 th Dec 2012 • Popcorn Hacking Guide – Generic modifications (all archs) • linux-3.2.14-popcorn-build.patch • linux-3.2.14-popcorn-syscall.patch • linux-3.2.14-popcorn-generic.patch – Architecture dependent in arch/x86 • linux-3.2.14-popcorn-x86-build.patch • linux-3.2.14-popcorn-x86-syscall.patch • linux-3.2.14-popcorn-x86-generic.patch • linux-3.2.14-popcorn-x86-apic.patch • linux-3.2.14-popcorn-x86-boot.patch • linux-3.2.14-popcorn-x86-vty.patch – Drivers modifications (all archs) in drivers/ • linux-3.2.14-popcorn-drivers-vty.patch • linux-3.2.14-popcorn-drivers-acpi.patch • linux-3.2.14-popcorn-drivers-gpu.patch • linux-3.2.14-popcorn-drivers-pci.patch • Goal – Release a first usable version of the project (alternative to virtual machines) – Document the project – Attract contributors and enthusiasts – Separate the architecture dependent code (initial porting guide) 2 Patches 25 th Mar 2013 • Goal – Release a new usable version of the project (replicated-kernel) – Add new components • Inter-Kernel Messaging layer • Remote process creation and migration • Other improvements and fixes 3 GIT Repositories • Hosted on TO BE ANNOUNCED – Publicly browseable, direct r/w access is protected (ssh key required) • Kernel code – TO BE ANNOUNCED – many different branches • davek – process/thread remote creation, migration • net_msg_integration – fast software network switch • shmem_tuntap – software network switch using TUN/TAP • bshelton_messaging – inter-kernel messaging layer • andy_fd_aware – NUMA aware scheduling • andy_load_balance – again, NUMA aware scheduling • mklinux-readonly – one page table per NUMA-node • etc.
    [Show full text]