XtratuM

XtratuM is a bare-metal hypervisor specially designed for embedded real-time systems available for the instruction sets LEON2/3/4 (SPARC v8) and ARM v7 processors. [1]

XtratuM
XtratuM architecture
Developer(s)Real-Time Systems group. Universidad Politécnica de Valencia
TypeHypervisor for safety-critical systems
LicenseGNU GPL-2.0
Websitewww.xtratum.org

It has been developed by the Universidad Politécnica de Valencia (Spain) with contributions of the Lanzhou University (China). XtratuM is released as free and open-source software, subject to the requirements of the GNU General Public License (GPL), version 2 or any later. Professional versions are commercialized by fentISS under a proprietary license. [1]

XtratuM is a hypervisor designed for embedded systems to meet safety critical real-time requirements. It provides a framework to run several operating systems (or real-time executives) in a robust partitioned environment. XtratuM can be used to build a MILS (Multiple Independent Levels of Security) architecture.

History

The name XtratuM derives from the word stratum. In geology and related fields it means:

Layer of rock or soil with internally consistent characteristics that distinguishes it from contiguous layers.

In order to stress the tight relation with Linux and the open-source movements, the “S” was replaced by “X”. XtratuM would be the first layer of software (the one closest to the hardware), which provides a solid basis for the rest of the system.

XtratuM 1.0 was initially designed as a substitution of the RTLinux HAL (Hardware Abstraction Layer) to meet temporal and spatial partitioning requirements. The goal was to virtualize the essential hardware devices to execute several OSes concurrently, with at least one of these OSes being a RTOS. The other hardware devices (including booting) were left to a special domain, named root domain.

After this experience, it was redesigned to be independent of Linux and bootable. The result of this is XtratuM 2.0 which is type 1 hypervisor that uses para-virtualization. The para-virtualized operations are as close to the hardware as possible. Therefore, porting an operating system that already works on the native system is a simple task: replace some parts of the operating system HAL with the corresponding hypercalls.

Overview

The design of a hypervisor for critical real-time embedded systems follows these criteria:

  • Strong temporal isolation: fixed cyclic scheduler.
  • Strong spatial isolation: all partitions are executed in processor user mode, and do not share memory.
  • Basic resource virtualization: clock and timers, interrupts, memory, CPU and special devices.
  • Real-time scheduling policy for partition scheduling.
  • Efficient context switch for partitions.
  • Deterministic hypercalls (hypervisor system calls).
  • Health monitoring support.
  • Robust and efficient inter-partition communication mechanisms (sampling and queuing ports).
  • Low overhead.
  • Small size.
  • Static system definition via configuration file (XML).

In the case of embedded systems, particularly avionics systems, the ARINC 653 standard defines a partitioning scheme. Although this standard was not designed to describe how a hypervisor must operate, some parts of the model are quite close to the functionality provided by a hypervisor.

The XtratuM API and internal operations resemble the ARINC 653 standard. XtratuM is not an ARINC 653 compliant system. The standard relies on the idea of a separation kernel defining both the API and operations of the partitions and also how the threads or processes are managed inside each partition.

XtratuM hypervisor supports the LEON 2/LEON 3/LEON 4 (SPARCv8) and Cortex R4/Cortex R5/Cortex A9 (ARMv7) architectures. [1]

XtratuM support as execution environments:

  • XAL (XtratuM Abstraction Layer) for bare-C applications
  • POSIX PSE51 Partikle RTOS
  • ARINC-653 P1 compliant LITHOS RTOS
  • ARINC-653 P4 compliant uLITHOS runtime
  • Ada Ravenscar profile ORK+
  • RTEMS
  • Linux
gollark: Are you on the galaxtonic ßerver?
gollark: That is not specific to the middle east.
gollark: The AST one sounds easier, do so.
gollark: ```osmarks@procyon ~> lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTmmcblk0 179:0 0 7.3G 0 disk ├─mmcblk0p1 179:1 0 2M 0 part ├─mmcblk0p2 179:2 0 2M 0 part ├─mmcblk0p3 179:3 0 1M 0 part ├─mmcblk0p4 179:4 0 1M 0 part ├─mmcblk0p5 179:5 0 1M 0 part ├─mmcblk0p6 179:6 0 1M 0 part ├─mmcblk0p7 179:7 0 4M 0 part ├─mmcblk0p8 179:8 0 8M 0 part ├─mmcblk0p9 179:9 0 8M 0 part ├─mmcblk0p10 179:10 0 4M 0 part ├─mmcblk0p11 179:11 0 1M 0 part ├─mmcblk0p12 179:12 0 1M 0 part ├─mmcblk0p13 179:13 0 1M 0 part ├─mmcblk0p14 179:14 0 1M 0 part ├─mmcblk0p15 179:15 0 1M 0 part ├─mmcblk0p16 179:16 0 2M 0 part ├─mmcblk0p17 179:17 0 20M 0 part ├─mmcblk0p18 179:18 0 5M 0 part ├─mmcblk0p19 179:19 0 1M 0 part ├─mmcblk0p20 179:20 0 16M 0 part ├─mmcblk0p21 179:21 0 16M 0 part ├─mmcblk0p22 179:22 0 200M 0 part ├─mmcblk0p23 179:23 0 1.5G 0 part │ ├─mmcblk0p23p1 254:0 0 94M 0 part /boot│ └─mmcblk0p23p2 254:1 0 1.4G 0 part /├─mmcblk0p24 179:24 0 150M 0 part ├─mmcblk0p25 179:25 0 9M 0 part └─mmcblk0p26 179:26 0 5.4G 0 part mmcblk0boot0 179:32 0 4M 1 disk mmcblk0boot1 179:64 0 4M 1 disk mmcblk0rpmb 179:96 0 4M 0 disk ```android_partition_scheme_irl
gollark: The GTech™ ones, with infinite processing power but somewhat limited memory.

See also

References
  1. https://fentiss.com/products/hypervisor/whats-xtratum/


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.