5. RTOS Guests (RT-Linux, VxWorks, On Time RTOS-32, …)

Important

You need to be familiar with chapter Hypervisor Guests - General before reading this chapter!

5.1. RTOS guests, general

Some ready to use RTOS images (containers) are provided, they are located in the respective template directory beyond /hv/templates (e.g. /hv/templates/rt-linux for RT Linux containers).

The first time an RTOS container is started, the RTOS Virtual Machine Framework (VMF) is loaded. Loading the VMF will also load the hypervisor configuration stored in the hv.config configuration file. This hypervisor configuration describes all guests and their related RTOS guest ID which is used to attach the guest to the VMF. In case a configuration entry has changed, all RTOS containers need to be stopped and the RTOS Virtual Machine to be reloaded. Configuration files are stored in *.config files.

5.1.1. RTOS Fileserver

The Hypervisor Host includes a file server which by default exposes the /hv/guests folder to RTOS guests.

The following configuration entry defines the root folder of the file server:

[Host\FileServer]
    "HomeDir"="/hv/guests"

The root folder is defined in /hv/config/hvbase.config for a System Manager based guest configuration or in one of the *.config files of the example guests.

This file server will use proprietary methods (using the Hypervisor’s RTOS-Library) to expose files in this folder. The RT-Linux and RTOS-32 guests include a filesystem driver for these methods.

5.1.2. RTOS guest folder

Besides the standard files described in General guest folder content, all RTOS guest folders contain the following additional file(s).

  • device.config: guest specific device configuration, you must not change this file

Additional configuration files may exist depending on the guest type and operation mode.

5.1.3. Log files

The following log files (located in the guest folder) will be created when starting a guest:

  • shutdown_svc.log guest shutdown service log messages.

  • shutdown_hook.log guest shutdown hook log messages.

5.2. Example Real-time Linux guest

See Real-time Linux Guest.

5.3. Example VxWorks guest

After the example is initialized, the VxWorks guest is located in /hv/guests/guestvxworks.

hv_open_example vxworks
hv_sync_example vxworks
cd /hv/guests/guestvxworks

Important

The shipped VxWorks image can only be executed if it is loaded into memory at a fixed address of 64 MByte. In the default configuration this is the case. When using the System Manager tool it must be configured as the very first Real-time guest.

5.3.1. File system access for VxWorks guests

To access the Hypervisor filesystem from within VxWorks, you may use FTP.

Follow these instructions to install an FTP server in the Hypervisor in case it is not yet installed.

  • activate the entry write_enable=YES in /etc/vsftpd.conf (you need to edit it with root rights)

  • create a new entry at the and of this file (this will become the root of the ftp filesystem): local_root=/hv/guests

  • Restart the FTP server: sudo systemctl restart vsftpd

  • Create an FTP user with the appropriate VxWorks client username and password (default is target with password vxworks):

    • run sudo adduser target

    • use the following password: vxworks

  • After executing the above steps, from within VxWorks, you should be able to access the guest folder via the VxWorks path pc:

  • If you need write access for the FTP client, you should do the following:

    • add the user target to the current user group: sudo usermod -aG $(whoami) target

    • for each folder that shall get write access run sudo chmod 775 /path/to/folder

5.4. Example On Time RTOS-32 guest

After the example is initialized, the RTOS-32 guest is located in /hv/guests/guestrtos32

hv_open_example rtos-32
hv_sync_example rtos-32
cd /hv/guests/guestrtos32

The guest image is selected through the osImage variable in the configuration script.

By default it is the RTOS-32 loader image /hv/templates/rtos-32/Loader.bin which is set in /hv/guests/guestrtos32/guest_config.sh. If you want to change the RTOS-32 image, you should set the osImage variable in the user specific guest configuration script usr_guest_config.sh.

If the Loader.bin is used, the loader will use the application DLL which is defined in the following configuration section in /hv/guests/guestrtos32/guest.config:

[Rtos\Loader]                           ; Used by Loader.bin
     "DllName"="rtos32app.dll"          ; File or link must exist in the guest directory

By default this is a link to the effective DLL: /hv/guests/guestrtos32/rtos32app.dlm which by default points to the RTOS-32Demo.dlm demo application.

You may select a different application, for example the RealtimeDemo as follows:

cd /hv/guests/guestrtos32
rm rtos32app.dlm
ln -s files/RealtimeDemo.dlm rtos32app.dlm

5.4.1. File system access for RTOS-32 applications

From within the RTOS-32 application you may access the Hypervisor filesystem via the C: drive. The root directory is set in guest.config in section [\\Host\\FileServer]. By default, it is set to the example guest folder at /hv/guests/guestrtos.

5.5. RTOS Shared Mode operation

Caution

This feature is not supported in RTOSVisor V8.1!

Using the RTOSVisor, Intel(c) VT technology allows to activate so called “Shared Mode”. In Shared Mode it is possible to run an RTOS on the same CPU as the Hypervisor Host (thus, the CPU is shared between two OSes). Please note, that hard real time for RTOS is also achieved in this mode.

Intel(c) VT-x and VT-d are hardware virtualisation extensions for Intel Processors. Please take a look at the official Intel page for full description of the technology: https://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.html

5.5.1. Activating VT

VT should be activated manually. In this example we configure a 2 CPU system, where the first CPU is used to run Hypervisor Host and RTOS1 (so, in shared CPU mode) and the second CPU will be used to run RTOS2 (as exclusive core).

This script installs necessary .deb packages, configures memory settings, reads ACPI tables and etc.

5.5.2. Linux Kernel grub parameters

IOMMU must be disabled in order to activate VT-D.

Add the following parameters to the linux kernel in grub.cfg: intremap=off intel_iommu=off maxcpus=1

Make sure these parameters have been removed: iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1

Currently only one shared cpu is supported. This is the reason, why maxcpus=1 is used.

5.5.3. Adapt .config files

  1. [Upload]

    "VersionDrv"=dword:9070000

  2. [Vmf]

    "VtAllowed"=dword:1

  3. [Rtos]

    "MemoryType"=dword:3

  4. [Rtos1]

    "MemoryType"=dword:3

  5. [Rtos\Vmf]

    "MapSystemTables"=dword:1

5.6. Achieving Hard Real-Time Capabilities

5.6.1. Background information

It is important to understand, which factors have influence to the real-time capabilities of your hardware. Most important of them are BIOS Settings (no CPU power saving modes should be activated, no CPU throttling, no variable CPU Frequency, USB Legacy support should also be disabled). System Management Interrupts (SMIs) must also be avoided.

5.6.1.1. Graphics

The video card has usually a huge impact on the real-time capabilities of the real-time system, because it cannot only generate SMI but also perform huge background DMA transfers from/to DRAM memory.

For example, if you have the Intel i915 video card on your Hypervisor Host, its Linux driver can produce significant interrupt/context latencies.

As a first step, in order to achieve better latencies, disable the LightDM graphics manager in your RTOSVisor host operating system. Simply run the following command sudo apt-get remove lightdm and then reboot your system.

This step converts your system into console only mode, no GUI. But it is not enough, because a video card can do DMA Transfers even without GUI.

The easiest and fastest solution here is to kill its driver as follows:

  • establish a connection with Hypervisor Host via SSH (port 22)

  • kill the video driver sudo rmmod -f i915. Now the computer monitor cannot be used anymore.

  • start realtime demo and make sure, that context switch/interrupt delays much better now (200%+):

5.6.1.2. CPU Core frequency policy

Intel processors with Hardware P-State (HWP) support delegate per-core P-state control to on-chip firmware via MSRs (Model-Specific Registers), rather than relying on legacy ACPI governors. HWP-capable CPUs expose:

  • IA32_HWP_CAPABILITIES (MSR 0x771) Describes the processor’s guaranteed performance range (min/max HWP indices), supported energy-performance preferences (EPP), and platform limits.

  • IA32_HWP_REQUEST (MSR 0x774) Allows software to request a target performance index and EPP hint on a per-core basis.

When HWP is enabled, the hardware governor automatically adjusts core frequency and voltage to satisfy requests written into IA32_HWP_REQUEST, providing smooth transitions and power-efficient operation. This can be used to optimize the performance and deterministic behavior for CPU cores used by Real-time operating systems.

Two commands simplify inspecting and updating per-core HWP settings:

  • hv_get_cpu_performance <CPU_ID>

    1. Verifies the logical CPU is online.

    2. Reads MSR 0x771 to obtain the “highest performance” index.

    3. Reads MSR 0x774 and decodes its four 8-bit fields: Desired, Minimum, Maximum, and EPP.

    4. Prints each field (hex and decimal) plus “Desired/Highest (%)” for quick comparison.

  • hv_set_cpu_performance <CPU_ID> <PERCENTAGE>

    1. Aborts if the CPU is offline (“CPU <CPU_ID> is offline.”).

    2. Reads MSR 0x771 to determine the maximum HWP index.

    3. Calculates:

      target = max(1, ceil(max_index × PERCENTAGE / 100))

      ensuring any non-zero percentage maps to at least index 1.

    4. Constructs a 32-bit HWP_REQUEST (Desired = Min = Max = target, EPP = 0x00 for maximum performance) and writes it to MSR 0x774.

    5. Prints the hex value written and a confirmation message.

Once a RTOS was started, the CPU may be offline. If a logical CPU is offline, the above commands will not work.

To bring a core back online:

hv_set_cpu_online <CPU_ID>

This script checks VMF status and, if unloaded, writes “1” to /sys/devices/system/cpu/cpu<CPU_ID>/online. Note that CPU 0 has no “online” file (always online), and the command will report that accordingly.

5.6.2. Real-time measurement

5.6.2.1. RT-Linux realtime demo

The shipped RT-Linux guests include a real-time measurement application.

Follow these steps to initialize the RT-Linux example and run the measurement:

hv_open_example rt-linux
hv_sync_example rt-linux
cd /hv/guests/guestrtlinux
hv_vmf_stop
hv_guest_start -view

Then log in (user = root, password = root)

RealtimeDemo

5.6.2.2. RTOS-32 realtime demo

You can use the RTOS-32 realtime demo application to determine the real-time capabilities of your system.

If you did not change the shipped RTOS-32 configuration, follow these steps to initialize the RTOS-32 example and run the measurement:

Initialize the RTOS-32 example

hv_open_example rtos-32
hv_sync_example rtos-32
cd /hv/guests/guestrtos32
mousepad usr.config

Add the following lines to modify the Fileserver path directing to the guest directory.

[Host\FileServer]
    "HomeDir"="/hv/guests/guestrtos32"

Update the link and start the application:

rm -f rtos32app.dlm
ln -s /hv/templates/example_guests/rtos-32/files files
ln -s /hv/guests/guestrtos32/files/RealtimeDemo.dlm rtos32app.dlm
hv_guest_start -view