The 1VM engine

Two engines, one product

These are not competing implementations of the same thing. They sit at different levels of Apple’s stack and are good at different jobs.

The rule of thumb: if Virtualization.framework can do your job, it should. The 1VM engine exists for the jobs it cannot.

What the engine actually is

Hypervisor.framework gives you very little and asks for a lot. It hands over the ability to create a virtual machine, map memory into it, run virtual CPUs and receive an exit when the guest does something that needs handling. Everything a guest recognizes as a computer, you build.

The core

One host thread per virtual CPU, guest memory mapped in at a 16 KiB granule, and Apple’s in-kernel GICv3 interrupt controller — which removes the single largest chunk of writing a hypervisor from scratch, because the interrupt distributor does not have to be emulated in userspace. Power management is the guest calling PSCI, handled in the hypervisor call handler. When the guest touches a device address, the engine decodes the faulting instruction and dispatches it.

The platform

Firmware is stock edk2, which is BSD-licensed. It is reused completely unmodified — not forked — which keeps firmware out of the tree entirely. Above it, the engine generates its own ACPI, flattened device tree and SMBIOS tables to describe the hardware it is presenting. For Windows this is the unforgiving part: a wrong entry in one of those tables is a black screen that looks exactly like success minus one field.

The devices

Every virtual device is a first-party model written from its public specification:

• Storage — NVMe for the Windows system disk, virtio-blk and virtio-scsi for Linux
• USB — an xHCI controller with HID keyboard, tablet and mouse, plus mass storage for installer media. The heaviest device in the engine.
• Network — virtio-net over a first-party user-mode NAT stack with DHCP, DNS and TCP/UDP port forwarding, or Apple’s vmnet
• Display — ramfb so firmware and Windows Setup are visible before any driver loads, then virtio-gpu
• The rest — PL011 serial, PL031 real-time clock, TPM, virtio input, console, RNG, vsock, balloon and virtiofs

Windows binds its own in-box drivers to NVMe, xHCI and PCIe, which is precisely why those are the devices that had to be built: they are the ones a guest expects to find without being given anything.

Why it replaced QEMU

Windows used to run by driving a QEMU process the user had to download. That worked. It was replaced for four reasons, none of which was performance.

Stated plainly so this does not read as a sales pitch: QEMU worked, and building a second hypervisor is the largest single undertaking in this codebase. The hard part was never Linux — it was Windows, where strict ACPI, NVMe and xHCI correctness is most of the calendar.

What is genuinely different

Three things follow from owning the engine rather than driving someone else’s, and they are the honest list.

• Nothing to download. Windows on ARM works from the app itself. There is no hypervisor to install alongside it, no Homebrew step and no version of an external tool to keep matched to the app.
• One process, so the display is the compositor. The guest framebuffer is presented into a Metal-backed window directly rather than being bridged out of another process. The same single-process design is what makes 1vm suspend — write guest memory to disk, power off, and resume later from exactly there — a thing the engine can do at all.
• No GPL in the bundle. The app is a signed, closed-source Mac application with no copyleft components to reason about, which is the whole reason the engine could be bundled rather than downloaded.

What is not different: raw CPU speed. Both engines run guest instructions natively on the Apple silicon cores through Apple’s hypervisor. Nobody is emulating instructions, so nobody is winning a benchmark because of it. Any page claiming the 1VM engine is “faster than QEMU” is one you should distrust — including this one, which is why it does not.

The clean-room rule

The license story is the entire point, and it only holds if the discipline holds. The rule the codebase enforces on itself:

A single copied file would turn “our engine” back into a derivative work — the exact problem the engine was built to escape.

Where it honestly stands

The engine ships in numbered capability tiers, each with a real exit criterion rather than a milestone that flatters itself. This is where it is:

1. N0–N1

   Core and firmware

   shipped

   vCPU loop, memory mapping, the in-kernel interrupt controller, timers, power management and MMIO decoding — then stock edk2 firmware booting to a UEFI shell on the platform the engine presents.

2. N2

   Linux parity

   where it is now

   An ARM64 Linux guest installs and runs with virtio block, network and display, shown in the 1VM console. Shipping and usable — but Virtualization.framework is still the default Linux path, because it is more mature and offers Rosetta.

3. N3

   Windows boots

   where it is now

   Windows 11 ARM completes an unattended install on NVMe and xHCI using in-box drivers, reaches a desktop, and takes keyboard and mouse input. New Windows machines default to this engine. This is where the product sits today.

4. N4

   Windows certification

   not yet

   Clean install, full stop, cold reboot, reset loops and a 24-hour soak all matching the old path. Not passed — which is exactly why the app labels the engine experimental rather than supported.

5. N5–N6

   Native GPU, warm snapshots

   not yet

   The in-process GPU device with zero-copy access to guest memory, and in-memory snapshot and restore. These are the strategic payoff the engine was built to make possible.

So: Windows boots and reaches a desktop on an engine with no external dependency, and that is real. It has not passed the certification gates that would let it stop being called experimental, and the app does not pretend otherwise — the engine picker states what each engine actually does at its current tier rather than showing one engine’s promises for another.

Pros and cons

Which engine should you use

In almost every case the app has already chosen correctly and you should leave it alone. For completeness:

Running macOS

Virtualization.framework. There is no choice to make — it is the only engine that can, and that will not change.

Running Linux

Virtualization.framework, the default. It is more mature, supports shared folders and clipboard more completely, and it is the only path with Rosetta for x86 Linux binaries. Choose the 1VM engine only if you specifically want the first-party device path — for example the bundled Omarchy image, which direct-boots its kernel on this engine.

Running Windows on ARM

The 1VM engine, which is the default for new Windows machines. The Virtualization.framework fallback exists but is genuinely worse for Windows: no TPM device, and Setup is often a black screen until a display driver binds. Just know that “experimental” on this engine is a real label, not a disclaimer.