MacHyperVSupport gives macOS a set of Hyper-V guest drivers

macOS as a guest on a Windows host, and the generations that work

The problem is that macOS was never written to run as a guest under Hyper-V, so a Mac VM on Windows needs guest-side drivers that Microsoft did not write and Apple did not either. MacHyperVSupport is that driver set. The README describes Hyper-V integration services for macOS running on Windows Server 2008 R2 or higher for generation 1 machines, and Windows 8.1 or Windows Server 2012 R2 or higher for generation 2. One combination is called out as unsupported: Windows Server 2016 with a generation 2 VM. All Intel macOS versions are supported, which is a meaningful limit in a market where Apple silicon is now the norm, and it is the same constraint that the rest of the project inherits. The intended user is someone running macOS inside a Windows environment, not a Mac developer on a Mac.

Two kexts and three daemons make up the deliverable

The binaries section lists six components, and they split cleanly into kernel extensions and user-space daemons. MacHyperVSupport.kext is the core Hyper-V support kext covering macOS 10.4 through 11.0, and MacHyperVSupportMonterey.kext is the core support kext for macOS 12.0 and newer, so the two together cover the whole Intel range. MacHyperVFramebuffer.kext is a basic framebuffer kext for all macOS versions, and the README notes that full synthetic graphics support requires it to be loaded or installed, and that on macOS 11.0 and newer it must be installed with kext signing disabled in SIP, because of Apple's requirements. The three daemons are hvfilecopyd for host to guest file copy, hvshutdownd for guest shutdown and hvtimesyncd for time synchronization. The three services that need a daemon are flagged as such in the supported device list, which is a useful hint about what will not work until you install them.

The supported device list tells you where the gaps are

The device list is the fastest way to understand the scope. Heartbeat, guest shutdown with daemon, time synchronization with daemon and host to guest file copy with daemon are all supported. PCI passthrough is listed as partial support, which is a polite way of saying it does not do everything you might want. Synthetic keyboard, synthetic mouse, synthetic network controller and synthetic SCSI controller are supported outright, while the PS/2 keyboard and the synthetic IDE controller apply to generation 1 VMs only, and the IDE controller currently only handles virtual hard disks. Synthetic graphics has the framebuffer condition attached to it. The credit list explains where some of the work came from: the Microsoft Hypervisor Top-Level Functional Specification is cited, and the Linux and FreeBSD Hyper-V integration services are credited, which tells you the design lineage is a port of the free operating system guests rather than something invented from scratch.

OpenCore needs three SSDTs, a set of quirks and kernel patches

The configuration burden is the real cost of this project, and the README is unusually detailed about it. Three ACPI tables are needed. SSDT-HV-VMBUS enables correct Startup Disk operation, SSDT-HV-DEV is required on Windows Server 2019, Windows 10 and newer, and provides proper processor objects while disabling incompatible virtual devices under macOS. SSDT-HV-PLUG ensures VMPlatformPlugin loads on Big Sur and above, which avoids freezes with the default PlatformPlugin. They must be added in that order, older macOS before 10.7 needs legacy iasl, and the patches described in the tables must also be present in the ACPI Patch section. Under Booter's Quirks, several settings are marked required, and the Kernel section needs Lilu and VirtualSMC as additional extensions, plus a set of named patches.

The kernel patches exist because the virtual hardware is not Apple hardware

The patches listed under Kernel are the most revealing part of the document, because each one exists to paper over a specific mismatch. The first disables _hpet_init, since there is no HPET hardware present. The second disables IOHIDDeviceShim::newTransportString(), a fix for a crash caused by a null _deviceType. The third disables the scaling factor for X and Y mouse movement, a workaround for the absence of AbsoluteAxisBoundsRemovalPercentage in 10.4. Under Force, older macOS versions may need IONetworkingFamily and IOSCSIParallelFamily injected, and IOGraphicsFamily must also be forced if the framebuffer kext is being injected on supported versions. The kernel quirks list adds ProvideCurrentCpuInfo as required for correct TSC and FSB values and CPU topology, and the Emulate section warns that dummy power management and CPU spoofing may be needed on older macOS depending on the host CPU.

Turning a DMG into a VHD or VHDX with qemu-img

The installation media step is the one concrete command sequence in the README, and it is short. Installer images can be passed in from USB hard disks, or converted from a DMG, with the caveat that DMGs need to be in a read/write format first. The conversion itself uses qemu-img, once for VHD and once for VHDX, with the format specified as raw on input and vpc or vhdx on output:

  - VHD: `qemu-img convert -f raw -O vpc Installer.dmg Installer.vhd`
  - VHDX: `qemu-img convert -f raw -O vhdx Installer.dmg Installer.vhdx`

The UEFI section is one line, and it is marked required on Windows Server 2019, Windows 10 and newer, with DisableSecurityPolicy. Boot arguments are not enumerated in the README, which instead points to the module list in Docs/modules.md, so the per-module arguments are something you look up rather than something the README repeats. The repository layout backs that up, with a Docs/ directory alongside the two kext source directories, the Xcode project, BuildScripts/ and Tools/.

A permissive licence and a 1.0.0 release after a long 0.9.x run

The licensing is BSD-3-Clause with the text in LICENSE.txt at the root, which is a permissive choice for a driver set that other people have to build and redistribute inside their own images. The release history explains the version numbers. Version 1.0.0 was tagged on 2026-09-27, and before it sat 0.9.9 from 2025-07-07 and 0.9.8 from 2025-03-04, so the project spent a long stretch in the 0.9 series before declaring 1.0, and the last push to the repository was on 2026-09-27. The README also carries a build status badge for the GitHub Actions workflow on the master branch and a Coverity scan badge, which tells you the project is built and statically analysed in CI. The Changelog.md file at the root is where the release notes live. None of this replaces the OpenCore work, which is the part that decides whether you get a bootable Mac in a Hyper-V guest.

Editorial conclusion

MacHyperVSupport suits someone who needs a macOS guest on a Windows Hyper-V host, for instance a build agent or a compatibility test machine, and who is prepared to work through the OpenCore configuration it documents. It does not suit a Mac user on Apple silicon, since every Intel macOS version is supported and nothing in the README covers Apple hardware, and it does not suit a Windows host on a generation 2 VM running Windows Server 2016, which the README lists as unsupported. Before adopting, read the ACPI and booter sections in full, confirm the framebuffer kext can be installed given the SIP requirement it names, and note that the last push to the repository was on 2026-09-27 with release 1.0.0 tagged the same day.

Frequently asked questions

Official sources

1. acidanthera/MacHyperVSupport on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases