Researcher pins Apple Silicon macOS VM cap to the kernel, spots boot-args that may control it

What happened

A developer digging into Apple Silicon virtualization hit a familiar brick wall: macOS hosts will only run two macOS guest VMs at once. The limitation surfaces as VZError.Code.virtualMachineLimitExceeded in Virtualization.framework, and the macOS Ventura SLA explicitly permits “up to two (2) additional copies” of macOS in virtual machines. Frustration turned to curiosity — why enforce this limit so strictly? It has been reported that the answer lives not in userspace frameworks but down in XNU, Apple’s kernel.

How they found it

Expecting a userland hard stop, the researcher instead compared Apple Silicon and Intel kernels via KDKs and disassembly. The investigation pointed at the hypervisor VM stack (hv_vm_*), with init code and bookkeeping functions such as hv_vm_destroy_0 and hv_trap_vm_create updating a kernel variable named hv_apple_isa_vm_quota. Digging required a development kernel (the Kernel Debug Kit) and tools to inspect the dyld shared cache and kernel binary. No, this wasn’t a cute little flag in a framework — it’s baked into kernel logic.

Why it matters

The implications are twofold. First, enforcing a VM cap in the kernel shows the limit is deliberate and robust against simple userland hacks. Second, the researcher allegedly found two boot-args — hypervisor= and hv_apple_isa_vm_quota= — that appear related to gating and quota control, suggesting researchers can at least observe and experiment with the enforcement point. That said, legal and practical limits remain: Apple’s license and future updates can undo tinkering, and poking kernel internals isn’t without risk. Two’s company, yes, but three’s apparently a crowd in Apple’s garden.

Takeaway

This isn’t an instruction manual or a jailbreak walkthrough. It’s a solid piece of reverse engineering showing where Apple chose to enforce a licensing limit: deep in XNU’s hypervisor layer. The write-up landed on khronokernel and sparked discussion on Hacker News, and it serves as a neat reminder — platform policy often lives in the plumbing, not the gloss.

Sources: khronokernel.com, Hacker News