Fusion Engine

Fusion is how MX runs a guest CPU. Native hardware virtualisation retires the work the host can actually host. The software ISA, IR, and translator retire the work it cannot. Fusion stitches the two so the guest sees one processor.

That path is the same on every host MX runs on: Windows, Linux, and macOS. The backend is WHPX, KVM, or Hypervisor.framework. The stack the guest sees does not change.

Two lanes

A native window retires guest instructions on the host virtualisation backend. Same-architecture EL0 and EL1 live here. Guest EL2 lives here too, when the selected backend can host it and the VM asked for it.

A software window retires guest instructions through MX's own execution engine: architectural semantics, the IR-JIT correctness path, and the fast translator for hot supported pairs. This is the lane that can own EL3. It is also the lane every guest falls to when the host cannot run a level, an instruction, or a register natively.

Fusion keeps the guest in a native window for as long as the architecture and the selected backend allow, takes a software-owned window for the rest, then returns.

The EL3 monitor

When the VM's highest advertised exception level is EL3, Fusion activates a monitor for that guest. The image is integer A64. Its vector table routes lower-AArch64 synchronous exceptions to an SMC handler. The installer supplies per-CPU secure stacks and the non-secure boot contract in ELR_EL3 / SPSR_EL3. Bootstrap is an ERET. SMC requests preserve most of the register file, normalise SMC32 widths, and forward service decisions to the engine. CPU_OFF, suspend, and shutdown are engine outcomes, not firmware polling loops.

Some boards already have a platform monitor. In that case Fusion keeps that contract and exposes EL2 to guest execution. The advertised cap is still EL3. The shared monitor is what generic AArch64 guests use when the board does not bring its own.

When native is used

Fusion uses a native window when the host backend can own that level and move the register banks the guest needs. If it cannot, software remains the owner. If the cap is EL3, the guest still has a monitor either way. Native windows are used when the host can actually do the work, not as a hope.

A trip through an SMC

The interesting transition is not a syscall. It is the guest asking for the secure monitor.

1. The guest at EL1 (or guest EL2) executes SMC.
2. The native vCPU exits to MX. That exit is not an entry into guest EL3. Real EL3 still belongs to the vendor ROM.
3. Fusion captures general registers, SIMD, and the system-register snapshot the native lane owns.
4. The software-owned monitor window retires the SMC, runs the service, and executes ERET.
5. State is restored. The native window resumes at the architected return level.

If the guest never touches EL3, native residency stays high. Enabling the level without using it is not supposed to tax ordinary OS code. The software path is still there for firmware that does use it, and for any instruction or register the native backend cannot run.

When Fusion steps aside

Auto mode takes native acceleration when the backend can host the requested cap, and the software engine when it cannot. Requiring hardware virtualisation reports an error instead of falling back. Disabling the hypervisor runs the entire guest on the software engine. The exception-level stack is still complete; only the native windows go away.

Cross-architecture guests never had native windows to begin with. Fusion still applies: the translator and IR-JIT are already the execution engine, and the same monitor image services SMC.