Rust Hypervisor with Dumarey

Supervised by a Politecnico di Torino professor together with a former technology officer at Dumarey.

Key contributions

• Developing a Type-1 hypervisor at EL2 in Rust for a multi-core Arm Cortex-R52 MCU, providing partition-based isolation for safety-critical automotive applications
• Implemented a static partitioning architecture in which VMs run natively at EL1, request EL2 services through HVC, and are memory-isolated by the stage-2 MPU; memory isolation and fault containment are verified on hardware
• Validated the ROM-to-EL2 boot path, RAM ECC, clock and cache setup, VM entry, HVC, and interrupt injection on target hardware, and implemented multi-core startup across clusters
• Generated the Rust peripheral access layer from the SoC’s SVD description using Infineon’s svd2pac, and built a typed model of the SoC’s devices and eDMA engines
• Structured the Rust SDK around separate EL1, EL2, and host deployment environments, with hardware-specific code isolated behind a board layer so the logic can be tested on the host
• Developed tracebridge, an open-source Rust CLI that automates PowerView startup, flashing, symbol loading, and RTT over the TRACE32 Remote API, serves as the backend of the board regression runner, and works with Lauterbach’s t32mcp to let an AI agent flash and debug

Background and goal

Dumarey is studying the feasibility of consolidating functions that are spread across several ECUs into one ECU. Several RTOS, AUTOSAR or bare-metal systems would then share one multi-core automotive MCU, and no system may silently corrupt another. With plain asymmetric multiprocessing, resource ownership is only a software convention: a faulty system can rewrite its own protection settings or access another system’s peripherals.

This project puts the final resource boundary at EL2, where VMs cannot change it. Each VM’s cores, memory, peripherals and interrupts are fixed before the build, and hardware mechanisms enforce them at runtime. A VM can reduce its own privileges but never enlarge them.

Architecture

Target architecture; click to enlarge. The EL1 ipc and services crates and the host deployment, codegen and CLI/GUI tools are not implemented yet; the table below shows current status.

• CPU: VMs run directly at EL1 with no binary translation; sensitive operations, HVCs and interrupts enter EL2. A core runs at most one VM, with no time-slice scheduling.
• Memory: the Cortex-R52 has MPUs rather than an MMU. The stage-2 MPU checks permissions but does not translate addresses, so each VM is linked for its assigned physical region. VMs are isolated but not transparently relocatable.
• Peripherals: each peripheral has one owner, and other VMs request a service from that owner instead of accessing it directly. This part is still in design.
• A small EL2: drivers, protocol stacks and application logic stay in VMs. EL2 only isolates resources and provides bounded services.

Current status

As of the end of October 2026. “Verified on board” means it ran on the target board and an automated check observed the behaviour.

The latest full board regression, on 28 October 2026, passed all 33 image runs and 32 reset checks. Another 103 host tests run without a board.

Technical challenges

Proving that isolation actually works

Debugger accesses bypass the MPU, so reading back a register shows only that the setting was written, not that it filters anything. Each isolation property therefore has its own fault image: a VM really reads, writes or fetches memory it does not own, and the check inspects the fault type and address recorded by EL2 and confirms the other cores were not affected. The blocked access itself is the evidence.

A latency measurement that exposed an ineffective cache

While comparing injected and passed-through interrupt latency, flushing the caches made almost no difference, which made no sense. Breaking the path down with on-chip trace showed that no single section was slow; every fetch of a new instruction block was. The root cause was that IMP_CSCTLR still held its reset value, which assigns no L1 cache ways to the Flash interface, so code and constants in Flash were never cached. The register can only be written before the caches are enabled, so each core now sets it in its startup path, and a regression check covers it. After the fix, the EL2 interrupt and HVC paths became clearly faster, and cold and warm runs finally differed.

Never leaving a half-started system

The design requires that either all VMs enter or none do. Each secondary core reports once when ready, and the primary core publishes one verdict after collecting the reports. Each barrier word has its own cache line and a single writer: the writer cleans and signals with sev, while the reader invalidates and waits in wfe, with a bounded wait. Each cluster has its own GIC distributor, reachable only from that cluster, so the lowest-numbered bound core in each cluster configures it.

Next steps

• Add bus-side isolation through on-chip firewalls and DMA control, which the CPU-side argument does not cover
• Implement inter-VM communication: one-way shared memory with event notification, with EL2 never copying message contents
• Research fault tolerance for automotive MCU reliability, with single event upsets among the fault classes considered. The plan is to use one core of the SoC together with TRACE32 to inject faults into a running partition, and record how the hypervisor detects them, contains them within that partition, and recovers