* Call blocks until the next VMEXIT of the vCPUĮxtern hv_return_t hv_vcpu_run(hv_vcpuid_t vcpu) _HV_10_10

* vcpu Pointer to the vCPU ID (written on success)Įxtern hv_return_t hv_vcpu_create(hv_vcpuid_t *vcpu, * Creates a vCPU instance for the current thread * flags READ, WRITE and EXECUTE permissions of the regionĮxtern hv_return_t hv_vm_map(hv_uvaddr_t uva, hv_gpaddr_t gpa, size_t size, * size Size in bytes of the region to be mapped * gpa Page aligned address in the guest physical address space * uva Page aligned virtual address in the current task * into the guest physical address space of the VM * Maps a region in the virtual address space of the current task * Creates a VM instance for the current taskĮxtern hv_return_t hv_vm_create(hv_vm_options_t flags) _HV_10_10 Here are some declarations from Hypervisor/hv.h: There is no real documentation, but the headers contain a decent amount of information. All we have to do is create a virtual CPU (or more!), set up all its state, assign it some memory, and run it… and then handle all “VM exits” – Intel lingo for hypervisor traps.

The idea is that the OS takes care of memory management (including nested paging) as well as scheduling virtual CPUs like normal threads. It enables apps to use virtualization without the need of a kernel extension (KEXT) – which makes them compatible with the OS X App Store guidelines. Since Version 10.10 (Yosemite), OS X contains amework, which provides a thin user mode abstraction of the Intel VT features.

Mac ox s 10.10 emulator