RTEMS Paravirtualization

Mentors: Julien Delange?

Status: New features to be designed. A previous GSOC project started to investigate this topic. See RTEMSSummerOfCode2011 and GSOC 2013 - Paravirtualization of RTEMS.

Introduction: The overall project consists in adapting RTEMS to be executed on top of an hypervisor so that we can run RTEMS instances on a partitioned kernel (such as ARINC653-related isolation layers like PikeOS, VxWorks?, etc...). To do so, it is necessary to (1) define a architecture-agnostic API to run RTEMS as a guest operating system and (2) tailor an existing hypervisor to execute RTEMS instances in several partitions.

Goal: make RTEMS compliant with partitioned kernel/isolation layer and make a proof-of-concept by collocating several RTEMS instances on top of an existing FOSS separation kernel

Requirements: low-level development, intel/sparc instructions, kernel design

Resources: Existing partitioning/isolation layer, such as POK (see or AIR (


Some projects provide software to isolate different RTEMS instance in a virtual machine (for example, Xtratum), and each need to tailor RTEMS for their own needs and adapt it to communicate with the hypervisor. Tailoring RTEMS for each hypervisor can be hard, especially since these solutions do not share/commit back their efforts; instead we want to define a generic adaptation layer that paravirtualizes RTEMS to ease the tailoring of RTEMS to run as a guest in a virtual machine. This project can proceed in two phases: one to design an adaptation layer for RTEMS paravirtualization and another to implement the interface for a particular hypervisor to execute RTEMS instances. For the second phase an open-source hypervisor should be used.

Proposed Approach

The project has two phases: paravirtualize RTEMS and adapt an existing partitioning kernel to execute RTEMS as a paravirtualized guest.

Paravirtualize RTEMS

Privileged instructions

This consists in reviewing RTEMS code and identifying which part of the code requires privileged instructions. After these code review efforts, the goal of this first activity would be used to design an architecture-agnostic API to execute privileged instructions. Basically privileged instructions would be wrapped so that when RTEMS is running as a guest OS it will instead make hypercalls to the hypervisor layer.

The API should be implemented for one or two architectures (initially x86 and SPARC are good targets) and lay the road map for more ports.

For that, the project could reuse the results of the previous Google Summer of Code project (in 2011) (see RTEMSSummerOfCode2011)

Devices and I/O

add details

Adapt existing isolation layer

Second step of this project is to adapt an existing partitioning kernel/isolation layer to execute RTEMS instances. Ideally, this would be implemented in an existing FOSS isolation layer. Actually, two FOSS projects provide such functionalities: Air and POK. Ideally, developers may evaluate the feasibility on each isolation kernel and choose the most appropriate solution.


Last modified on Feb 14, 2015 at 7:15:06 PM Last modified on Feb 14, 2015, 7:15:06 PM