Hacker News Reader

Comment by slig | Hacker News Reader

LTT [1] did a video recently about running macOS on a Linux host using QEMU. Anyone here tried that? If so, what's the experience like? Thanks

[1]: https://www.youtube.com/watch?v=ATnpEOo3GJA

View on HN

I do this using Proxmox (QEMU under the hood), and it's been mostly a nice experience. I currently run 3 VMs on a single Linux box with 3 GPUs (one per VM via VFIO passthrough). I've used both NVIDIA and AMD graphics cards with success. Before Mojave, NVIDIA cards were easier with their web driver, but Apple and NVIDIA don't get along in Mojave (both companies are blaming each other) and there is no web driver. So for macOS, I've switched to an AMD GPU which works mostly out of the box, apart from needing a small tweak in the Linux host's kernel parameters ("disable_idle_d3=1" to avoid a bug preventing the device from being used after a VM restart).

To get macOS to see my GPUs with full acceleration and audio over HDMI, I use the Clover bootloader to inject a small section into the DSDT, mapping the emulated PCI address to a device that actually looks like a graphics card to macOS. This same DSDT patch works for both NVIDIA and AMD GPUs (the ones I've tried anyway).

The best thing about Hackintosh in a VM is that you no longer need to fear macOS upgrades. Just create a snapshot, try the upgrade, and if it doesn't work out, you can restore, investigate, and try again.

LTT's video is a nice overview, but his claim that "because this is a VM... it will run on any hardware" isn't quite true when talking about GPUs. Unlike the CPU, memory, and some other devices, the GPU is seen (nearly) directly by the guest VM, so guest OS support is in fact required to see the advantages of GPU passthrough.

In summary, it's never going to be super easy, but it's not too difficult either, and the performance (and flexibility) is actually really great.

Thank you very much for sharing your experience.

Thats sounds pretty interesting. Ive been running a hacked together windows VM gaming setup via qemu with vfio passthrough for the past 1.5 years on my local linux server. Im pretty pleased with it. Ive got it down to simply executing a small script and everything comes up. It could be even more automated using evdev potentially (recognizing mouse/keyboard events).

I was thinking about expanding the setup to include a beefier linux host (more gpus and better hardware) and more seats -- windows gaming for me and osx for my wife. But you mentioned several possible osx specific caveats: amd gpus, clover (?) bootloader w/ dsdt (?), disable_idle_d3, etc. Can you link to some info or READMEs regarding your setup or how you came across these solutions?

I don't have any specific guides about my setup, but here are a few things that have been helpful to me:

- Good starting point for setting up macOS under QEMU/KVM: https://github.com/kholia/OSX-KVM

- DSDT/SSDT patching: https://www.tonymacx86.com/threads/ssdt-gpu-graphics-card-in...

- AMD reset bug: https://www.reddit.com/r/VFIO/comments/5h351m/gpu_stuck_in_d...

- Kernel extension that can help with some GPU issues: https://github.com/acidanthera/WhateverGreen

The DSDT/SSDT patch was probably the trickiest thing. I've posted my particular patch here if you're interested: https://pastebin.com/ngvkVZYN

Also, a few of my other scripts/config: https://pastebin.com/9Nh5rheZ

Thank you for the links. Time to build a new server!

In case anyone runs across similar AMD GPU issues, the "disable_idle_d3=1" option in the second pastebin link (when used as a kernel parameter) should be prefixed as "vfio-pci.disable_idle_d3=1". Even then, it can still be hit-or-miss with some cards (it works most of the time for me, but some VM restarts still find that the GPU has entered D3 and won't come back without rebooting the host).

is this a macOS guest specific issue? would I have similar issues on a Windows or Linux guest?

I believe it happens for any guest OS (search for "amd reset bug"). Some people are using a workaround that involves removing the device (in the sysfs), suspending the host, and then rescanning, but for me, that's not much better than a host reboot, so when the AMD GPU occasionally does get stuck in D3 (preventing starting the VM after a VM reboot), I just reboot the host. It doesn't happen very often, and when it does, it's only when I'm in the process of rebooting the VM anyway.

Previously, I also attempted using a kernel patch that's been floating around (DECLARE_PCI_FIXUP_HEADER ... quirk_no_bus_reset), but it just gives me corrupt graphics when rebooting the VM.

I am building a VFIO build this weekend. one of the goals is to power a macOS VM for work. if I remember I will update you on my experience.

I had success getting macOS running on QEMU with my existing PC, but its performance suffered without a dedicated GPU and CPU pinning, which my new build will be configured to handle

Thank you, hope your build goes well!

Reply on news.ycombinator.com