macOS already ships the driver.Reims vGPU is the device it talks to.
macOS already ships the driver.
Reims vGPU is the device it talks to.Accelerated graphics for unmodified macOS guests under QEMU. The guest uses Apple's own `AppleParavirtGPU.kext` — no kext to install, no guest driver, stock macOS. Reims vGPU decodes the command stream on the host and executes it through Vulkan.
QEMU — macOS 13 Ventura guest · reims-vgpu-pci
$ vm/boot-x86.sh --testing --device reims-vgpu-pci
“macOS 13 on QEMU.” — video by @bzai56
Read this first
Alpha means alpha.
Reims vGPU is research-quality software for experimentation and bring-up — not a frozen virtualization product. Four facts to calibrate expectations:
Everything can change
The QEMU device ABI, boot scripts, crate layout, backend behavior, and supported pathways may change without a stable compatibility guarantee.
macOS 13 Ventura is the target
Ventura is the guest release the project is used and tested against, on both working pathways. Other macOS versions may or may not work.
Vulkan works; Metal is planned
The working host backend is Vulkan — directly on Linux, and through MoltenVK on macOS. A direct Metal backend is a TODO, not a feature.
Independent of Apple
Reims vGPU is an independent open-source project. It is not affiliated with, sponsored by, or endorsed by Apple Inc.
See it run
The whole desktop, in a window.
macOS 13 Ventura with accelerated graphics on both working pathways — an Apple Silicon host and a Linux x86 host, running the same stock guest.
arm64 · Apple Silicon host
arm64 Ventura guest on macOS, attached via `reims-vgpu-mmio`.
x86\_64 · Linux host
x86\_64 Ventura guest under KVM, attached via `reims-vgpu-pci`.
How it works
One command stream, guest to GPU.
The path a frame takes from an app inside the VM to pixels in the host window. All device logic lives in Rust; the C shim stays thin on purpose.
1. 01
Metal.framework
Apps in the guest call Metal, exactly as they would on real hardware. 2. 02AppleParavirtGPU.kext
Apple’s own paravirtual GPU driver ships with macOS — and binds to the Reims vGPU device unchanged. 3. 03Command stream
Rings over PCI BAR (x86\_64) or sysbus MMIO (arm64) carry Metal-style commands to the host. 4. 04QEMU shim
A deliberately thin C layer in the vendored QEMU fork wires QOM, MMIO/BAR, IRQ/MSI and forwards into Rust via HostOps. 5. 05Rust core
Protocol decode, device model, memory mapping, scheduling. Nothing fails silently — declined commands carry typed reasons. 6. 06Host GPU
Vulkan on Linux; Vulkan via MoltenVK on macOS. Shaders translate Metal AIR → SPIR-V through metal2vulkan. Direct Metal: planned.Pathways
Three ways to run it.
Two combinations work today and one is on the bench — each pairs a specific host, guest, and backend. macOS 13 Ventura is the recommended guest on all of them.
HostLinux x86\_64, KVM
Guestx86\_64 macOS 13 Ventura
Devicereims-vgpu-pci (PCI)
BackendVulkan via metal2vulkan
Bootvm/boot-x86.sh
HostApple Silicon macOS, HVF
Guestarm64 macOS 13 Ventura (vmapple)
Devicereims-vgpu-mmio (sysbus MMIO)
BackendVulkan via metal2vulkan, through MoltenVK
Bootvm/boot-arm64.sh
HostApple Silicon macOS, HVF
Guestarm64 macOS 13 Ventura (vmapple)
Devicereims-vgpu-mmio (sysbus MMIO)
BackendMetal, direct — not yet implemented
Bootvm/boot-arm64.sh
Contribute
How you can help.
The project is at the stage where careful systems work moves the needle. Contributions are especially welcome on:
- correctness & visual glitches
- synchronization bugs
- command-stream decoding
- Metal ↔ Vulkan translation
- more reliable host/guest combinations
The project family
reims-vgpuMain repo: QEMU shim (vendored), Rust device & backends, VM scripts.metal2vulkanMetal AIR → SPIR-V shader translator, native Rust emitter. Library + CLI.qemu-reims-vgpuQEMU fork carrying the thin device shim, vendored as vendor/qemu.