Why Virtualization on Microcontrollers?

Virtualization creates logical copies of the same hardware so that multiple bare-metal programs and operating systems can coexist on one physical platform. On the PC, monitors such as VMware and VirtualBox have shaped IT infrastructure for decades. RVM brings the same idea to microcontrollers — for reasons that are specific to embedded systems.

There are two flavors of virtualization: full virtualization runs an unmodified OS image; paravirtualization adapts the OS bottom layer to the monitor. RVM uses paravirtualization to minimize time and memory overhead, exposing a small set of hypercalls for sensitive privileged operations.

On MCUs, the case for virtualization rests on three pillars.

Reliability

Traditional RTOSes reach reliability through static analysis and certification. That is not enough, because errors also enter the system from outside the RTOS:

• Application bugs. Traditional RTOSes provide no memory isolation of any kind — a bug in one task propagates easily and can destroy the entire software system.
• Radiation and EMI. External interference flips bits in hardware and causes sporadic errors throughout the system.
• Denial of service. A single high-priority thread stuck in a loop makes the whole system unresponsive; repeatedly calling a scheduler-locking system call degrades hard real-time behavior even further.
• Sabotage. Without memory protection, an intruder can corrupt an IoT device at will.

Watchdog resets mitigate this only for simple applications. For complex or critical systems that cannot afford a full reboot, traditional RTOSes have no answer — a monitor with per-VM isolation does.

Security

Traditional RTOSes generally do not treat information security as a design goal. A buffer overflow is usually enough to take full control, and the consequences can be far worse than simple sabotage:

• In smart homes, cameras and appliance controls can be hijacked.
• In smart cars, attackers have forced drivers into unwanted behavior — this has happened on production vehicles.
• In life-support devices such as medical ventilators, simply shutting the machine down is fatal.
• In industry, whole production lines can be stopped.

Virtual machines are inherently modular and confinable, and the underlying RME system adds capability-based security on top.

Flexibility

The embedded software market has always been fragmented: incompatible RTOSes and stacks, each targeting its own niche. That was acceptable while embedded systems did one dedicated thing — but IoT devices now integrate ever more functions.

Instead of building one RTOS with every feature, virtualization lets different software stacks coexist on the same chip. New application forms become possible, and programmers keep their existing mental model of RTOS development — there is virtually no learning cost.

Would virtualization not be too costly?

No. If the monitor is well designed and used correctly (especially the communication mechanisms), the overhead is negligible. A virtualized FreeRTOS has a context-switch and interrupt-response time of roughly 4x the bare-metal original — yet it remains about 25x faster than RT-Linux. For CPU-bound virtual machines that do little I/O, the overhead is effectively zero.

4x context switch and interrupt latency — acceptable?

For the MCUs RVM targets, yes. The monitor aims at high-end MCUs whose bare-metal response time is overkill for most sensors and actuators. A Cortex-M4 @ 180 MHz running virtualized FreeRTOS responds like a Cortex-M3 @ 72 MHz running bare-metal FreeRTOS.

In I/O terms the Cortex-M3 is already sufficient — the M4 is chosen for compute, not for response time. If you truly need the lowest latency, write RME native applications, whose response time is comparable to bare-metal FreeRTOS. On anything faster than a Cortex-M4 (Cortex-M7, TMS320C66x), the overhead question disappears entirely.

How much code must I change to port?

Very little — see the user manual for details. Many software packages are already available on the platform, so most users do not port anything at all: check the guest support matrix first.