FAQ

As a Type I (bare metal) hypervisor the RTS Hypervisor securely splits the PC into separate hardware partitions, each consisting of one or more CPU cores, memory, timers, and I/O devices. By default hardware is not shared between operating systems, which also includes the CPU cores, i.e. the operating systems run in parallel without interrupting each other. Several different execution modes are provided, from full isolation to hard real-time. Unlike real-time extensions (where resources for real-time tasks are provided by a host OS) the RTS Hypervisor makes sure real-time tasks cannot be compromised by other operating systems. Having one OS open to end users and / or connected to the outside world while another OS runs critical code is one of the typical use-cases. Running a mix of real-time and non-real-time operating systems is just a matter of configuration.

The RTS Hypervisor offers different modes of deploying an operating system.

• The fully monitored mode, where operating systems run completely unmodified in a secure partion. In this mode it is guaranteed, that the OS can not impair or affect other operating systems running in parallel in any way. However, this comes at the expense of a slight performance hit.
• In order to guarantee hard real-time and determinism for real-time code or real-time operating systems, the RTS Hypervisor also features a deployment mode called the "privileged mode". In the privileged mode, operating systems retain full hardware access and use a paravirtualization interface provided by the RTS Hypervisor. This allows operating systems to run at native speed without any latencies added by the Hypervisor.
• Security options like MMU virtualization, I/O restrictions, and IOMMU can be turned on selectively.
• Shared resources like last level cache or memory bus access can be prioritized between operating systems.

The RTS Hypervisor is very flexible. No matter if a low-power module or a multi-socket server is used, the exact same Hypervisor binary is executed. This allow the RTS Hypervisor to run on any PC and application specific "customizations" are just a matter of configuration.

The RTS Hypervisor runs on any modern x86 based PC with any chipset. Certain features (e.g. IOMMU) may require hardware support.

For last level cache allocation CAT is required.

To protect memory on device level and to relocate operating systems, an IOMMU is required.

While caches in general reduce jitter, shared caches may cause operating systems to be influenced by each other. If the processor supports Cache Allocation Technology (CAT), a cache that would otherwise be shared can be separated into OS-exclusive caches.

All standard BIOS or EFI-base Firmware (with or without CSM) are supported. If general-purpose operating systems run on the PC without modifications the RTS Hypervisor will run on the system as well.

To make the RTS Hypervisor run no special features are required. However, certain desirable hardware features may need to be enabled by the firmware.

After the regular firmware execution, a bootloader loads the Hypervisor which then initializes the hardware and starts the various operating systems in the selected boot sequence. Both, bootloader as well as Hypervisor can be configured to be invisible to the end user.

Out of the box, the RTS Hypervisor currently supports Microsoft Windows 10 and older, Windows Embedded Compact, VxWorks, XENOMAI, TenAsys Intime distributed RTOS,  RTOS-32, QNX, Linux, real-time Linux and T-Kernel. Support for other operating systems can be added anytime upon request. Different operating systems may run in different execution modes at the same time and any mix of SMP and single-CPU, 32-bit and 64-bit is possible.

Operating systems can be updated anytime without our help, even by the end user.

If your OS, e.g. Microsoft Windows requires an installation to disk, you may first install the operating system(s) and then proceed with the Hypervisor installation. In case operating systems do not require an installation on disk, the RTS Hypervisor can also load images directly from a specified location.

For OS development standard tools can be used. In order to configure the RTS Hypervisor no development tools are required.

Any standard debug tools and interfaces can be used. This includes tools for kernel debugging as well as application debugging. Unique about the RTS Hypervisor is the possibility to debug your real-time target e.g. from another core executing Windows in parallel via the virtual network. No specialized tool or training is required.

None, you may assign devices exclusively to operating systems and use existing device drivers without modifications.

Any standard PCI or PCIe devices can be assigned exclusively (pass-through). Devices like AHCI or xHCI controllers can be shared between operating systems.

Yes, pass-through is actually the default assignment mechanism used by the RTS Hypervisor. Memory and device protection is achieved through MMU virtualization and IOMMU.

Yes, AHCI sharing allows for assignment of disk drives or disk partitions and xHCI sharing allows for assignment of xHCI ports.

As PCI and PCIe devices can be assigned exclusively and existing device drivers can be used any field bus or real-time ethernet protocol can be used.

All networking devices can be assigned and existing drivers and protocols can be used.

Via an internal (TCP/IP) virtual network or inter-OS event system.

Yes, if multiple memory controllers are present, indiviual memory nodes can be assigned to operating systems.

The RTS Hypervisor is not based on any other software. This is important as existing solutions like KVM or XEN are designed for different use cases. The RTS Hypervisor has been developed solely by Real-Time Systems in Ravensburg, Germany and is not subject to export restrictions.

Where full isolation is used a few percent virtualization overhead can be measured. Naturally, running multiple operating systems on the same hardware each of which having fewer CPUs and less memory available results in lower overall performance in a guest OS compared to a native OS execution where all hardware is available.

The RTS Hypervisor has an execution mode in which no latencies are added through virtualization. In this mode the determinism of an OS may even be better than without Hypervisor, considering that the RTS Hypervisor reduces power management impacts and allows for load balancing, i.e. devices not required for the real-time application may be handled by another OS. On the other hand, using shared resources may have an impact on the determinism.

General-purpose operating systems like Windows or Linux can be installed in their typical way. Installation of the RTS Hypervisor is a matter of installing another bootloader and putting some files into the file system. To make use of our communication methods and APIs the drivers we provide have to be installed.

Installation of the RTS Hypervisor and initial configuration is a matter of minutes and doesn't require training. Any technical questions that may arise will be answered by our support team.

Yes. APIs to monitor, start, stop, reboot operating systems are provided and permissions can be configured selectively.

The real graphics (GPU) can be made available to an OS (this is even the default) and the native graphics driver with all its capabilities can be used.