Skip to content


Browse files Browse the repository at this point in the history
  • Loading branch information
mist64 committed Jun 10, 2015
1 parent 04180a5 commit 6322d86
Show file tree
Hide file tree
Showing 173 changed files with 18,296 additions and 24,466 deletions.
103 changes: 103 additions & 0 deletions Makefile
@@ -0,0 +1,103 @@
ifeq ($V, 1)


VMM_SRC := \
src/vmm/x86.c \
src/vmm/vmm.c \
src/vmm/vmm_host.c \
src/vmm/vmm_mem.c \
src/vmm/vmm_lapic.c \
src/vmm/vmm_instruction_emul.c \
src/vmm/vmm_ioport.c \
src/vmm/vmm_callout.c \
src/vmm/vmm_stat.c \
src/vmm/vmm_util.c \
src/vmm/vmm_api.c \
src/vmm/intel/vmx.c \
src/vmm/intel/vmx_msr.c \
src/vmm/intel/vmcs.c \
src/vmm/io/vatpic.c \
src/vmm/io/vatpit.c \
src/vmm/io/vhpet.c \
src/vmm/io/vioapic.c \
src/vmm/io/vlapic.c \
src/vmm/io/vpmtmr.c \

src/acpi.c \
src/atkbdc.c \
src/block_if.c \
src/consport.c \
src/dbgport.c \
src/inout.c \
src/ioapic.c \
src/md5c.c \
src/mem.c \
src/mevent.c \
src/mptbl.c \
src/pci_ahci.c \
src/pci_emul.c \
src/pci_hostbridge.c \
src/pci_irq.c \
src/pci_lpc.c \
src/pci_uart.c \
src/pci_virtio_block.c \
src/pci_virtio_vmnet.c \
src/pci_virtio_rnd.c \
src/pm.c \
src/post.c \
src/rtc.c \
src/smbiostbl.c \
src/task_switch.c \
src/uart_emul.c \
src/xhyve.c \
src/virtio.c \


SRC := \
$(VMM_SRC) \

OBJ := $(SRC:src/%.c=build/%.o)
DEP := $(OBJ:%.o=%.d)
INC := -Iinclude

TARGET = build/xhyve

all: $(TARGET) | build

.PHONY: clean all

-include $(DEP)

@mkdir -p build

build/%.o: src/%.c
@echo cc $<
@mkdir -p $(dir $@)
$(VERBOSE) $(ENV) $(CC) $(CFLAGS) $(INC) $(DEF) -MMD -MT $@ -MF build/$*.d -o $@ -c $<

$(TARGET).sym: $(OBJ)
@echo ld $(notdir $@)
$(VERBOSE) $(ENV) $(LD) $(LDFLAGS) -Xlinker $(TARGET).lto.o -o $@ $(OBJ)
@echo dsym $(notdir $(TARGET).dSYM)
$(VERBOSE) $(ENV) $(DSYM) $@ -o $(TARGET).dSYM

$(TARGET): $(TARGET).sym
@echo strip $(notdir $@)
$(VERBOSE) $(ENV) $(STRIP) $(TARGET).sym -o $@

@rm -rf build
184 changes: 184 additions & 0 deletions
@@ -0,0 +1,184 @@
# xhyve

<!-- -->


The *xhyve hypervisor* is a port of [bhyve]( to OS X. It is built on top of Hypervisor.framework in OS X 10.10 Yosemite and higher, runs entirely in userspace, and has no other dependencies. It can run vanilla Linux distributions and may gain support for other guest operating systems in the future.

License: BSD

Introduction: [](


* OS X 10.10 Yosemite or later
* A 2010 or later Mac


$ make

The resulting binary will be in build/xhyve


$ xhyve -h

What is bhyve?

bhyve is the FreeBSD hypervisor, roughly analogous to KVM + QEMU on Linux. It has a focus on simplicity and being legacy free.

It exposes the following peripherals to virtual machines:

- Local x(2)APIC
- 8259A PIC
- 8253/8254 PIT
- PM Timer
- host bridge
- passthrough
- AHCI (i.e. HDD and CD)
- VirtIO block device
- VirtIO networking
- VirtIO RNG

Notably absent are sound, USB, HID and any kind of graphics support. With a focus on server virtualization this is not strictly a requirement. bhyve may gain desktop virtualization capabilities in the future but this doesn't seem to be a priority.

Unlike QEMU, byhve also currently lacks any kind of guest-side firmware (QEMU uses the GPL3 [SeaBIOS](, but aims to provide a compatible [OVMF EFI]( in the near future. It does however provide ACPI, SMBIOS and MP Tables.

bhyve architecture
I/O VM control FreeBSD NetBSD
| A | A | |
V | V | V V
| || || || |
| bhyve || bhyvectl || bhyveload || grub2-bhyve |
| || || || |
| || || || |
| libvmmapi |
| user
| ioctl FreeBSD kernel
| VMX/SVM host |
| VMX/SVM guest |
| VMX/SVM nested paging |
| Timers |
| Interrupts |


The bhyve FreeBSD kernel module. Manages VM and vCPU objects, the guest physical address space and handles guest interaction with PIC, PIT, HPET, PM Timer, x(2)APIC and I/O-APIC. Contains a minimal x86 emulator to decode guest MMIO. Executes the two innermost vCPU runloops (VMX/SVM and interrupts/timers/paging). Has backends for Intel VMX and AMD SVM. Provides an ioctl and mmap API to userspace.


Thin abstraction layer between the vmm.ko ioctl interface and the userspace C API.


The userspace bhyve component (kind of a very light-weight QEMU) that executes virtual machines. Runs the guest I/O vCPU runloops. Manages ACPI, PCI and all non in-kernel devices. Interacts with vmm.ko through libvmmapi.


Somewhat superfluous utility to introspect and manage the life cycle of virtual machines. Virtual machines and vCPUs can exist as kernel objects independently of a bhyve host process. Typically used to delete VM objects after use. Odd architectural choice.


Userspace port of the FreeBSD bootloader. Since bhyve still lacks a firmware this is a cumbersome workaround to bootstrap a guest operating system. It creates a VM object, loads the FreeBSD kernel into guest memory, sets up the initial vCPU state and then exits. Only then a VM can be executed by bhyve.


Performs the same function as bhyveload but is a userspace port of [GRUB2]( It is used to bootstrap guest operating systems other than FreeBSD, i.e. Linux, OpenBSD and NetBSD.

Support for Windows guests is work in progress and dependent on the EFI port.

xhyve architecture
| xhyve |
| |
| I/O |
| |
| |
| |
|| vmm VMX guest ||
|| Timers ||
|| Interrupts ||
| Hypervisor.framework |
| user
|syscall xnu kernel
VMX host
VMX nested paging

xhyve shares most of the code with bhyve but is architecturally very different. Hypervisor.framework provides an interface to the VMX VMCS guest state and a safe subset of the VMCS control fields, thus making userspace hypervisors without any additional kernel extensions possible. The VMX host state and all aspects of nested paging are handled by the OS X kernel, you can manage the guest physical address space simply through mapping of regions of your own address space.

*xhyve* is equivalent to the *bhyve* process but gains a subset of a userspace port of the vmm kernel module. SVM, PCI passthrough and the VMX host and EPT aspects are dropped. The vmm component provides a libvmmapi compatible interface to xhyve. Hypervisor.framework seems to enforce a strict 1:1 relationship between a host process/VM and host thread/vCPU, that means VMs and vCPUs can only be interacted with by the processes and threads that created them. Therefore, unlike bhyve, xhyve needs to adhere to a single process model. Multiple virtual machines can be created by launching multiple instances of xhyve. xhyve retains most of the bhyve command line interface.

*bhyvectl*, *bhyveload* and *grub2-bhyve* are incompatible with a single process model and are dropped. As a stop-gap solution until we have a proper firmware xhyve supports the Linux [kexec protocol](, a very simple and straightforward way to bootstrap a Linux kernel. It takes a bzImage and optionally initrd image and kernel parameter string as input.


- vmm:
- enable APIC access page to speed up APIC emulation
- enable x2APIC MSRs (even faster)
- vmm_callout:
- is a quick'n'dirty implementation of the FreeBSD kernel callout mechanism
- seems to be racy
- fix races or perhaps replace with something better
- use per vCPU timer event thread (performance)?
- some 32-bit guests are broken (support PAE paging in VMCS)
- PCID guest support (performance)
- block_if:
- OS X does not support preadv/pwritev, we need to serialize reads and writes for the time being until we find a better solution.
- support block devices other than plain files
- virtio_net:
- make it not require root
- unify TAP and vmnet backends
- performance: send/receive more than a single packet at a time
- ACPI tables don't work
- bhyve creates ASL on the fly and then calls out to an ASL compiler (iasl) on
every VM boot to create the DSDT:
- remove dependency on iasl by creating AML bytecode directly
- shouldn't be to hard since we we are only interested in a very small
subset of ASL
- virtio_rnd:
- is untested
- remove explicit state transitions:
- since only the owning task/thread can modify the VM/vCPUs a lot of the synchronization might be unnecessary
- performance, performance and performance
- remove vestigial code, cleanup
50 changes: 0 additions & 50 deletions bhyve/Makefile

This file was deleted.

0 comments on commit 6322d86

Please sign in to comment.