The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors Gernot Heiser Ben Leslie Open Kernel Labs and NICTA and Open Kernel Labs University of New South Wales Sydney, Australia Sydney, Australia [email protected] [email protected] ABSTRACT high-performance OKL4 microkernel for mobile devices [OKL4] We argue that recent hypervisor-vs-microkernel discussions com- (with more than 750 million instances shipped to date). pletely miss the point. Fundamentally, the two classes of systems Curiously, this did not stop a new debate starting a number have much in common, and provide similar abstractions. We assert of years back, this time pitting microkernels against hypervisors, as if they were disjoint classes of systems. Some of these ar- that the requirements for both types of systems can be met with a + single set of abstractions, a single design, and a single implementa- guments [HWF 05] we have earlier shown to be based on false tion. We present partial proof of the existence of this convergence premises [HUL06], others [AG09] are based on an outdated, 1980’s point, in the guise of the OKL4 microvisor, an industrial-strength view of microkernels, oblivious to the last 15+ years of microkernel system designed as a highly-efficient hypervisor for use in embed- research. ded systems. It is also a third-generation microkernel that aims We assert that these arguments completely miss the point. Mi- to support the construction of similarly componentised systems as crokernels and hypervisors are both designed as low-level founda- classical microkernels. Benchmarks show that the microvisor’s vir- tions for larger systems, although with different objectives. This tualization performance is highly competitive. does not mean that these objectives are irreconcilably at odds. In fact, we argue that we can construct a type of kernel that satisfies the combined objectives of microkernels and hypervisors. We call Categories and Subject Descriptors such a kernel a microvisor, and present the OKL4 microvisor as a D.4.7 [Operating Systems]: Organization and Design—Real-time representative. systems and embedded systems In the next section we revisit the motivations for microkernels and hypervisors, and the resulting objectives and designs. In Sec- General Terms tion 3 we explore the intersection of these objectives and present the OKL4 microvisor as a representative. Section 4 presents initial Design, Performance performance data and Section 5 discusses related work. Keywords Microkernels, hypervisors, virtual machines, real-time systems and 2. MICROKERNELS AND HYPERVISORS embedded systems 2.1 Microkernels 1. INTRODUCTION While the term microkernel was not coined until a decade and a The merits of microkernels have been debated for a long time. half later, the basic concept goes back to Brinch Hansen’s nucleus Popular in the 1980s, they fell into disrepute in the early ’90s as [BH70]. The basic idea is to reduce the kernel code to fundamental systems built on top failed to perform. Arguments that the perfor- mechanisms, and implement actual system services (and policies) mance problems were inherent in the microkernel approach [CB93] in user-level servers. The microkernel is supposed to be general were refuted by Liedtke [Lie95] identifying design and imple- enough to support the construction of arbitrary systems on top. mentation shortcomings of these first-generation kernels, and it The modern microkernel concept is captured in Liedtke’s Mini- was demonstrated that the second-generation (2G) L4 microkernel mality Principle: A concept is tolerated inside the microkernel only could be used as a hypervisor to virtualize Linux with an over- + if moving it outside the kernel, i.e. permitting competing imple- head of about 5–7% [HHL 97]. Commercial microkernels are mentations, would prevent implementation of the system’s required now deployed at a large scale, including QNX [LG09] for high- functionality [Lie95]. availability, Green Hills Integrity [GHS] for high security, and the The original driver behind microkernels is generality and flexi- bility, based on a separation of policy and mechanisms [LCC+75]. A more modern motivation is the design of systems with a minimal Permission to make digital or hard copies of all or part of this work for trusted computing base, in order to aid assurance of safety- and personal or classroom use is granted without fee provided that copies are security-critical systems [HPHS04]. The formal verification of the not made or distributed for profit or commercial advantage and that copies seL4 microkernel [KEH+09] shows that microkernels can be small bear this notice and the full citation on the first page. To copy otherwise, to enough make a formal proof of functional correctness feasible. republish, to post on servers or to redistribute to lists, requires prior specific Moving services out of the kernel into servers makes client- permission and/or a fee. APSys 2010, August 30, 2010, New Delhi, India. server communication performance-critical, and as such a micro- Copyright 2010 ACM 978-1-4503-0195-4/10/08 ...$10.00. kernel needs a very fast inter-process communication (IPC) mech- 19 anism. Consequently, IPC performance used to be the focus of the actual device driver residing inside the hypervisor—this microkernel research [Lie93]. approach supports multiplexing the device (like other re- sources). Sometimes a device is made directly accessible to 2.2 Hypervisors the guest by mapping device registers into the guest’s mem- Hypervisors are even older, they go back to the 1960s. The orig- ory and virtualizing interrupts (the hypervisor up-calls the inal motivation was an early form of legacy re-use: With the ad- guest’s interrupt handler routine). This makes multiplexing vent of more powerful computers, the original single-user single- of stateful devices difficult or impossible and, in the case of task model of operating systems was no longer sufficient. Virtual- DMA-capable devices, can only be done securely with addi- ization supported the concurrent execution of programs by putting tional hardware support (I/O MMU). each into a separate virtual machine (VM), together with its single- Microkernels, in contrast, tend to run device drivers as sep- tasking executive. Virtualization went out of fashion in the ’70s arate user-level processes, which communicate with the rest with the widespread availability of multitasking and multi-user of the system using IPC. This is effectively a combination of OSes, until its renaissance in the last decade, mostly driven by the the approaches discussed for hypervisors, and supports de- resource-management deficiencies of most modern OSes. vice sharing without making drivers part of the microkernel, According to the classic definition, a VM is an efficient, isolated but comes at the expense of additional context switches. duplicate of a real machine [PG74]. The VM is implemented by a hypervisor (or virtual-machine monitor, VMM) which provides Communication Subsystems need to communicate. VMs com- virtual resources either by (temporarily) mapping them to physical municate like real machines—via networks. Hence, hypervi- resources, or emulating them. The former is efficient, the latter sors traditionally provide virtual networks, which are based results in overhead, and so is avoided where possible. on the existing virtual-device abstraction, running standard While originally virtualization was understood to be pure (vir- networking stacks. Microkernels, in contrast, are designed tual resources are essentially indistinguishable from real ones), for systems decomposed at a much finer granularity, and hardware limitations and efficiency reasons led to widespread use therefore offer highly-optimised message-based IPC primi- of para-virtualization, which presents a modified hardware ABI tives. Following Liedtke [Lie93], 2G microkernels typically to which the guest OS is ported. A hypervisor supporting para- minimise overheads by providing a synchronous (blocking virtualization provides extra APIs, called hypercalls, which gener- and unbuffered) IPC primitive. ally are more high-level than the hardware ABI. 2.3 Comparison In summary, there is not much difference in the first three points. As far as I/O is concerned, hypervisors have in recent years moved In summary, microkernels aim to provide a minimal layer of closer to microkernels. Xen [BDF+03], for example, runs its ad- privileged software, while hypervisors aim to replicate and mul- ministrative functions in a privileged VM called Domain0, which tiplex hardware resources. Both have an inherent need to abstract hosts a Linux guest. Domain0 is also used as a source of de- the hardware, although with different emphasis. vice drivers, which therefore run in user mode, as with a micro- For a hypervisor it is fundamentally important that the abstract kernel (although all the Domain0 drivers run in the same address (“virtual”) resources look as much like the concrete (“real”) ones space, that of the Linux guest). The driver (excuse the pun) behind as possible, while implementation size is not a primary concern. this development is the cost of re-implementing or adapting device For a microkernel, similarity of real and abstract resources is not drivers: Domain0 uses unmodified drivers from the Linux guest. a driver, but in reality the semantic gap cannot become very large This in turn puts pressure on inter-VM communication costs. without violating the minimality requirement. Only a few years back, hypervisor proponents belittled the mi- It should now not be overly surprising that the abstractions end crokernel community [HWF+05] for their efforts in optimising up being quite similar. Fundamentally, both types of kernels must IPC. During the discussion following the presentation of that pa- provide abstractions for: per, a prediction was made that within two years the hypervi- Memory: The hardware managing memory is the MMU, and hy- sor community would be publishing papers on improving inter- pervisors provide a virtual MMU, or virtualize the MMU’s VM communication overheads. In fact, a string of papers have software interface, the page tables.