Virtualisation

Learn is a guided walk through how virtual machines actually work: hypervisors, Arm exception levels, MX's Fusion Engine, and the ways a guest talks to disks, graphics, and real hardware. Start here if you have never sat with a hypervisor before.

A hypervisor multiplexes one physical machine so several guests can each believe they own a CPU, memory, and a set of devices. That belief is the product. Everything else is machinery for keeping it true without letting a guest walk into host memory or steal the host's privilege stack.

What a hypervisor does

Two jobs, always:

1. Run guest instructions. When the guest architecture matches the host, those instructions can retire on the host CPU under hardware virtualisation. When it does not, they have to be decoded and translated.
2. Intercept the operations that would let a guest escape. Privileged registers, physical page tables, device DMA, and interrupt controllers all belong to the machine, not to the guest's idea of the machine.

The host occupies the hypervisor privilege level. Guests run beneath it. That is true whether the product on top is a type-1 hypervisor OS or a type-2 desktop app.

Type 1 and type 2

A type-1 hypervisor is the operating system. MXE is built that way: install it on bare metal, then boot guests. ESXi and a Hyper-V root partition are the same shape.

A type-2 hypervisor is a process on a general-purpose OS. MX Studio talks to the host's virtualisation API: KVM on Linux, Hypervisor.framework on macOS, WHPX on Windows. The hardware primitive is the same in every case. The host still occupies EL2 on Arm, or VMX/SVM root on x86. The difference is who owns the rest of the machine: a dedicated hypervisor OS, or a desktop OS sharing the cores with the guests.

Same-architecture versus translation

MX runs x86_64, aarch64, and arm64e guests. When the guest and the host share an architecture, the vCPU can use the host's virtualisation extensions and retire ordinary arithmetic, loads, and branches as real instructions.

When they do not share an architecture, MX falls to the translation engine. Hot blocks translate straight between aarch64 and x86_64. Everything else lowers to IR, is optimised and verified, then JITs. Both routes emit through the same backends, so the fast path cannot quietly drift from the slow one.

What the guest is allowed to see

A thin wrapper around stock virt is easy to detect. Guests that probe SMBIOS, ACPI, CPUID, or PCI IDs will find a hypervisor. MX's machine models are built the other way: chipsets, firmware tables, and extension sets that look like the hardware they claim to be. Virtio is still available when you want a guest-aware paravirtualised device. Stealth Configuration is the option that rewrites identities so software looking for a VM sees a commodity PC.

The next article is the reason this is harder on Arm than the x86 picture suggests: the host already occupies two of the four exception levels, and it cannot give them away.