RTEMSHyperVisor

This project is just an idea at this point. You can make of it what you will. Be creative. Some ideas are captured here. No idea is more important than the others.

Tailoring RTEMS to support hypervisor/virtual machine

The idea of this project is to ease the integration of RTEMS with hypervisor/supervisor/IMA platforms. At this time, some projects already provide software to isolate different RTEMS instance in a virtual machine (for example, Xtratum). It needs to tailor RTEMS for their own needs and adapt it to communicate with the underlying hypervisor. However, this approach requires to tailor RTEMS for each hypervisor, which can be hard, especially because this adaption efforts are not shared and duplicate code. This project aims at defining a generic adaptation layer to ease the tailoring of RTEMS to hypervisor and provide an open-source/free software hypervisor implementation example. So, it consists in two parts : one to design an adaptation layer to ease the tailoring of RTEMS with hypervisors and another that would consist in providing an hypervisor to execute RTEMS instances. For the second part, existing hypervisor/virtual machine can be used (such as POK or Xtratum) but the solution has to be released under free-software license so that everybody can use it at his convenience.

As a result, this project would really use the integration of RTEMS into IMA architectures and would enable the design of ARINC653 systems with inter-partitions services.

L4

RTEMS has been run on the L4 hypervisor so that should be a strong foundation for some types of hypervisor work.

ARINC653 API support

The goal is to provide a minimal ARINC653 layer? that support only intra-partition services. As inter-partitions would be managed by an underlying hypervisor, they must be integrated as a second step for ARINC653 services integration. The idea here would be to provide an API that support the first part of ARINC653 services so that ARINC653 application can compile with RTEMS and intra-partition services would work. This implies to add a new API support in RTEMS. The project would enable the following services to be interfaces with the regular RTEMS API: tasks, intra-partition (blackboard/event/semaphore/buffer) and time service. For inter-partition services (queueing/sampling ports), we expect to provide the definition of the function but leave it blank so that an ARINC653 partition would compile but the behaviour would have to be implemented in the future.

RTEMS Virtual Machine Monitor

Status: No active volunteers.

RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS can not support to run another OS (such as Linux or uClinux). We want to add hypervisor (or Virtual Machine Monitor) function on RTEMS, then RTEMS has the power like XEN that can run Linux or other OS, but RTEMS also maintain original hard Real-Time funtions. First, we will try to make RTEMS run uClinux on ARM simulator SkyEye? ( ​http://www.skyeye.org ), then we will try to make RTEMS run ARM Linux on XSCALE CPU based board or SkyEye? simulator. We consider virtualization techs on Embedded RTOS area has potential value. (from chyyuu@…)

I am VERY fond of the idea of a free hypervisor that provides the real-time features required by ARINC 653. --Dr. Joel? 23:18, 25 January 2010 (UTC).

The implementation of ARINC 653 interface in RTEMS was studied as part of a ESA project named AIR. This study was developed to "study of how the Real-Time Executive for Multiprocessor Systems (RTEMS) can be adapted to fullfill the requirements defined in the ARINC 653 standard". The project provided a proof of concept of the ARINC 553 implementation. The project page can be found ​here. The final report can be found ​here. "This document: (i) describes the main issues regarding the AIR architecture specification;(ii) addresses how space and time partitioning could be provided in an abstract processor infrastructure, as well as those requirements can be mapped into both SPARC ERC32/LEON and Intel IA-32 (80x86) architectures;(iii) describes how to achieve the mapping of the ARINC 653 service interface in RTEMS;(iv) identifies the most relevant module dependencies of RTEMS with regard to AIR implementations;(v) identifies a preliminary set of modifications to be introduced in the RTEMS application production chain for the implementation of AIR-based systems (exemplified through a proof of concept prototype)." Quoted from ​http://hdl.handle.net/10455/2982 . -- cdcs ​research paper