Xtratum: an Open Source Hypervisor for Tsp Embedded Systems in Aerospace
Total Page：16
File Type：pdf, Size：1020Kb
XTRATUM: AN OPEN SOURCE HYPERVISOR FOR TSP EMBEDDED SYSTEMS IN AEROSPACE A. Crespo1, I. Ripoll1, M. Masmano1, P. Arberet2, and J.J. Metge2 1Instituto de Informatica´ Industrial, Universidad Politecnica´ de Valencia, Spain 2CNES, France ABSTRACT several independent execution environments1 in a single computer. The key difference between hypervisor tech- nology and other kind of virtualizations (such as java vir- XtratuM is an hypervisor designed to meet safety critical tual machine or software emulation) is the performance. requirements. XtratuM 2.1.0 is a redesign of the former Hypervisor solutions have to introduce a very low over- version XtratuM 2.0 (for x86 architectures) to meet safety head; the throughput of the virtual machines has to be critical requirements. It has been ported to SPARC v8 very close to that of the native hardware. Hypervisor is a arquitecture and specially to the to the LEON2 proces- new and promising technology, but has to be adapted and sor, which is the reference platform for the spatial sec- customized to the requirements of the target application. tor. Adaptation involves a strong effort in redesign to be As far as we know, there are no previous experiences with closer to the ARINC-653 standards. As far as we know, hypervisors for spatial systems. XtratuM is the first hypervisor for the SPARC v8 arqui- tecture. In this paper, the main design aspects are dis- When a hypervisor is designed for real-time embedded cussed and the internal architecture described. An ini- systems, the main issues that have to be considered are: tial evaluation of the most significant metrics is also pro- temporal and spatial isolation, basic resource virtualisa- vided. tion (clock and timers, interrupts, memory, cpu time, se- rial i/o), real-time scheduling policy, deterministic hyper- Key words: Partitioning systems, hypervisors,micro- visor system calls, efficient inter-partition communica- kernels. tion, efficient context switch, low overhead and low foot- print. In this paper, we present the design, implementation and 1. INTRODUCTION evaluation of XtratuM for the LEON2 processor. Al- though XtratuM was initially implemented for x86 archi- Although virtualisation has been used in mainframe sys- tectures, its porting to LEON2 has implied a strong effort tems since 60’s; the advances in the processing power of in redesign and implementation due to the architecture the desktop processors in the middle of the 90’s, opened constraints. the possibility to use it in the PC market. The embedded market is now ready to take advantage of this promising technology. Most of the recent advances on virtualization 2. VIRTUALISATION TECHNOLOGIES have been done in the desktop systems, and transferring these results to embedded systems is not as direct as it may seem. Attending to the resources used by the hypervisor there are two classes of hypervisors called type 1 and type 2. The current state of the visualizing technology is the re- The type 1 hypervisors run directly on the native hard- sult of a convergence of several technologies: operating ware (also named native or bare-metal hypervisors); the system design, compilers, interpreters, hardware support, second type of hypervisors are executed on top of an op- etc. This heterogeneous origin, jointly with the fast evo- erating system. The native operating system is called host lution, has caused a confusion on the terminology. The operating system and the operating systems that are exe- same term is used to refer to different ideas and the same cuted in the virtual environment are called guest operat- concept is differently named depending on the engineer ing systems. background. Although the basic idea of virtualizing[Cor] is widely A virtual machine (VM) is a software implementation understood: “any way to recreate an execution environ- of a machine (computer) that executes programs like a ment, which is not the original (native) one”; there are real machine. Hypervisor (also known as virtual ma- chine monitor VMM [Gol74]) is a layer of software (or 1We will use the terms:guest, virtual machine and partition as syn- a combination of software/hardware) that allows to run onyms. substantial differences between the different technologi- Micro-kernel was initially presented as a solution (the cal approaches used to achieve this goal. right way to do) to the supposed problems of the mono- lithic kernels2. This strong (and enforced by the micro- Virtualizing is a very active area, several competing tech- kernel) isolation between the components of the oper- nologies are actively developed. There is still not a clear ating system prevents that an error on a component af- solution, or a winner technology over the rest. Some vir- fects the behavior of the rest of the system. Although the tualizing technologies are better than other for a given tar- microkernel technology was developed as a paradigm to get. For example, on desktop systems, para-virtualization implement a single operating system, the services pro- is the best choice if the source code of the virtualized en- vided by the micro-kernel can be used to build several vironment is available, otherwise full-virtualization is the different operating systems, resulting in a virtualized sys- only possible solution. tem. Currently the main drawback is the non negligi- A detailed description and analysis of the techniques and ble overhead introduced by the communication mech- the existing solutions is beyond the scope of this report anism, and the high abstraction level of the processor. (the reader is referred to the document “Virtualization: The virtualized operating system must be highly modi- State of the Art” [SCO08]). Just to summarise the current fied (ported) to meet the micro-kernel API and philoso- available solutions for the real-time embedded systems: phy. The micro-kernel approach started with the March micro-kernel. The most representative implementation of a micro-kernel is the L4 [Lie95]. 2.1. Separation kernel 2.3. Bare-metal hypervisor Also known as operating system-level virtualization. In this approach the operating system is extended (or im- It is a thin layer of software that virtualizes the criti- proved) to enforce a stronger isolation between processes cal hardware devices to create several isolated partitions. or groups of processes. Each group of isolated group of The hypervisor also provides other virtual services: inter- processes is considered a partition. In this solution, all partition communication or partition control services. the partitions must use the same operating system. It is like if several instances of the same O.S. were executed The hypervisor does not define an abstract virtual ma- in the same hardware. chine but tries to reuse and adapt to the underlying hard- ware as much as possible to reduce the virtualization An important disadvantage of the this solution is the large overhead. In other words, the virtual machine will be amount of code and the high complexity (the whole O.S.) close to the native hardware in order to directly use the of the virtualizer. native hardware as much as possible without jeopardiz- ing the temporal and spatial isolation. Several hypervi- sors are available for general purpose operating systems. 2.2. Micro-kernel This was originally an architectonic solution for develop- 2.4. Para-virtualization ing large and complex operating systems. The idea was to separate the core kernel services from the rest of more The para-virtualization (term coined in the complex and “baroque” services. The core kernel ser- Xen [DFH+03] project) technique consist in replacing vices are implemented by a layer of code called micro- the conflicting instructions3 explicitly by functions kernel, and consist of: context switch, basic memory provided by the hypervisor. In this case, the partition management, and simple communication services (IPC). code has to be aware of the limitations of the virtual Only the micro-kernel code is executed in processor environment and use the hypervisor services. Those privileged-mode, the rest of the operating system subsys- services are provided thought a set of hypercalls. tems (scheduler, user process management, memory ser- The hypervisor is still in charge of managing the hard- vices, filesystem, network stack, etc.) are implemented ware resources of the systems, and enforce the spatial and as micro-kernel thread. The operating system itself is de- temporal isolation of the guests. Direct access to the na- signed as a set of cooperating servers; each server is a tive hardware is not allowed. thread with its own protected memory space and commu- nicated with other servers via the micro-kernel IPC facili- The para-virtualization is the technique that better fits ties. The micro-kernel implements only the mechanisms; the requirements of embedded systems: Faster, simpler, the policies are implemented by the micro-kernel threads smaller and the customization (para-virtualization) of the at user level (even the scheduling policy). guest operating system is not a problem because the source code is available. Also, this technique does not requires special processor features that may increase the “The microkernel implements only the mechanism to cost of the product. select one of the time partitions as active foreground partition. The policy part of deciding which of the 2Linux is a monolithic kernel. time partitions is activated when is left to the user 3Conflicting instructions: instructions that operate directly on the level. ...” native hardware and may break the isolation. 2.5. Dedicated devices the standard, it was developed considering that the under- laying technology used to implement the partitions is the In the server and desktop segments, the virtualizer pro- separation kernel. Athough it is not an hypervisor stan- vides a complete (or full) virtualized environment for dard, some parts of the APEX model of ARINC-653 are each virtual machine. That is, the each virtual machine very close to the functionality provided by an hypervisor.