"Feels native" is a specific claim, not a vibe

Pin it down concretely: a shell inside the guest doesn't have perceptible input lag. git clone, npm install, apt upgrade don't feel like they're paying a tax compared to running the same command on the host. Compiling a moderately sized project doesn't visibly drag. None of that is marketing language — it's the observable effect of the CPU trap, memory-translation, and interrupt-delivery costs staying cheap enough that a human can't feel them, which is a real engineering outcome, not an accident of expectation.

The old prior wasn't wrong — it was about different hardware

This is worth knowing because it explains where the "VMs feel slow" instinct actually comes from. x86 wasn't originally built to be virtualized at all: the architecture has around 17 instructions that are sensitive to privilege level but don't cleanly trap to a hypervisor, so a classic trap-and-emulate approach simply couldn't virtualize all of it. VMware's answer in 1998 was binary translation — real engineering, but software papering over a gap in the silicon. Hardware support didn't arrive until years later: Intel's VT-x in 2005, AMD-V in 2006, both retrofitted onto an architecture that had already shipped for decades without virtualization in mind.

ARM's virtualization extensions didn't have that history to work around. EL2, the dedicated hardware exception level for the hypervisor, was part of the architecture's own design rather than a later patch — covered in full in the performance deep dive. Apple Silicon inherits that clean design, not decades of x86-specific workarounds. That's the actual, explainable reason the "VMs are inherently a little slow" prior doesn't hold up here the way it might from older x86 experience.

What this buys you concretely

Translated into day-to-day terms rather than mechanism: cheap CPU traps mean a shell prompt in the guest responds the way a native one does. Hardware-assisted interrupt delivery means network-heavy operations — docker pull inside the guest, a git fetch against a large repo — aren't paying a per-packet hypervisor tax. TLB-cached two-stage memory translation means a memory-heavy compile isn't quietly re-walking page tables on every access. None of these are separately tunable settings; they're properties of the platform every workspace gets by default.

Unified memory makes VM sizing simpler, too

Apple Silicon's unified memory architecture means there's no separate VRAM pool competing with system RAM the way there is on a PC with a discrete GPU. A guest's memory is just a slice of that same fast, unified pool — handed out at boot and reclaimable via the memory-balloon device covered in the device inventory post when the guest isn't using it. Sizing a VM's memory on a Mac is a more predictable exercise than it is on hardware where "how much is actually free" depends on what the GPU has claimed separately.

The honest exceptions

"Feels native" is a scoped claim, not a blanket one, and it's worth being direct about where it stops. A Linux guest gets no GPU compute passthrough at all — a real limitation covered in the fundamentals post, and exactly why AI Bridge keeps the model on the host GPU instead of trying to get compute into the guest. And none of this native feeling extends to a different CPU architecture: an x86_64 guest, or an emulated --platform linux/amd64 container pull, is genuinely slower, for the categorical reasons covered in ARM64 vs. x86-64 on Apple Silicon. Same-architecture Linux is where this claim lives; it was never a claim about everything.

Related reading: the full mechanics behind this, what a VM on Apple Silicon actually is, and the real benchmark numbers in the inference benchmark. Or download Velo Workspaces and try it yourself.