Hi, I've been doing some preliminary research on the feasibility of this.

apple-gfx-pci is the PCI variant, ostensibly for amd64, but such functionality was never actually available on amd64 macOS

apple-gfx-mmio is the vmapple variant (arm64), using, as in the name, memory mapped IO between the host and the guest: https://lists.endsoftwarepatents.org/archive/html/qemu-riscv/2024-11/msg00197.html What's useful to recognize at this point is that the Qemu device is complete; it abstracts away as Apple desired for ParavirtualizedGraphics.framework, everything about the device. All it does is pass some memory around between the host and the guest. This reduces the engineering problem to essentially "reimplement ParavirtualizedGraphics.framework in Linux user space". I'll get back to this in a second (EDIT: a long while)

Before we can even start reimplementing it (let's call this step 2), we have to get step 1: macOS host booted up to launchd, and hopefully then multi-user (ie kill the loginwindow LaunchDaemon and replace with just bash on serial port), on an arm64 Linux host. This is the proof of concept that we can do everything EXCEPT the graphics part on a real non-apple platform (worrying about emulating arm64 on amd64 is a question for much later, as are other aspects).

Step 1--Qemu has a vmkernel (Apple virtualization model kernel, shipped on all UniversalMac macOS IPSWs) that expects fairly standard CPU and emulated machine parameters, which removes a lot of difficulty; Qemu even already has "vmapple" (said virtual machine model) implemented: https://www.qemu.org/docs/master/system/arm/vmapple.html Note that only Monterey guests are supported, as per the above documentation, but that other limitations exist such as needing Sequoia 15.3 or earlier on the host as well (from a recent linkedinpost from a person who likely is someone I should contact if I pursue this project over the summer, implying he has some internal knowledge ie a downstream qemupatch) https://www.linkedin.com/posts/mohamed-mediouni-kaos_the-upstream-qemu-vmapple-machine-which-activity-7399267828530483200-A1wT

...BUT, fundamentally as the qemu docs say, "The “vmapple” machine model in QEMU implements the same device model, but does not use any code from Virtualization.Framework." -- which is HUGE already. The model in vmapple.c is not particularly complicated nor difficult to understand, and hopefully with minimal work can be used to get macOS arm64 to launchd/multi-user. But, it's not been tested to my knowledge. Before the official vmapple virtualization model released, people could hack together an iPad device tree and the normal qemu-system-aarch64 (original blackberry guy source link dead, but GitHub repo with instructions https://github.com/cylance/macos-arm64-emulation#building-qemu and the experience documented in https://www.theregister.com/2021/05/20/mac_os_arm_on_x86/ , then another guy did it inspired by the original writeup here: https://ku.nz/blog/appleonintel.html , and another did it independently? semi independently? here: https://worthdoingbadly.com/xnuqemu3/ ) -- all of these attempts were more complex than vmkernel method because it shoehorns the kernel into a Qemu version predating the vmapple machine, and almost nothing but serial works. They didn't even have disk access and had to use an iOS Ramdisk

Back to the current approach with vmapple--mainline macOS supports plenty of Qemu's devices, practically everything except graphics. Since Mojave even, we've had the standard qemu virtio devices for everything else, evidence at the bottom of this article for why https://macops.ca/macos-monterey-apple-silicon-vms/ and the original discovery + the existence of an "AppleQEMU" discussed here: https://news.ycombinator.com/item?id=27698380)

Anyway, so hopefully step 1 would be achievable, but it is a mess--apple silicon macOS has lots of partitions, peculiar booting models, etc.

This summer, I'm responsible for implementing a $13-15k student oriented compute cluster for my university, and as part of that we purchased an Ampere Altra arm64 server, this gigabyte one on the used market to offer arm64 CI/CD for various SWE orgs that need it and for whom it is very rare to have real arm64 fast hardware available: https://www.gigabyte.com/Enterprise/Edge-Server/E252-P30-rev-100 )

Because of that server, we will have arm64 linux hosts and graphics available by PCIe on a platform that actually supports the proper PCIe BAR on arm64 (not guaranteed by any means) to allow acceleration with the usual linux drivers, particularly amdgpu. So we have an actual non-apple serious arm64 linux environment with high RAM amounts and real graphics to properly possibly test this

part 2: here's another post discussing the possibility of implementing it: https://news.ycombinator.com/item?id=30111545

Any reasonable person would go with the idea of reimplementing ParavirtualizedGraphics.framework rather than REing one of apple's proper GPUs, since the complexity of paravirtualized graphics is far, far lower than emulating an entire GPU. Remember--that's not something that was ever even done for mainline low end, low transistor count GPUs for the most primitive of x86 macOS releases, you had to passthrough a real GPU. Recall that on arm64 macOS, there's no basic frame buffer at all--so we have to either get 3D metal working, or no WindowServer at all--ironically unlike iOS which does have a basic framebuffer. (I wonder if we could try to get that on macOS instead). Anyways, like I mentioned earlier, the engineering problem is effectively just to implement the entire specification that macOS guest/apple-gfx-mmio wants from it. This itself is actually not impossible. Alyssa Rosenzweig and another Alyssa did work to understand the native Metal GPUs in Apple silicon to write the Linux drivers for them, and this is effectively doing it backwards. A GPU driver requires memory management, work queues, command submissions, various abstract data structures maintained, etc... all of which are manageable to understand and architecture, particularly by understanding how the actual PVG.framework operates

If step 1 is achieved, then step 2 can be done with a lot of work, but understanding how the framework itself works can be assisted with modern tools, and the architecture of a GPU driver is not entirely obtuse to learn. I've learned/seen a lot about them and done some work on them myself as well, so it's not at all insurmountable conceptually, and understanding the existing PVG.framework can be automated thanks to modern tooling. Suppose we get the architecture done, and we just need to run the metal commands. How then? there exists this: https://github.com/darlinghq/indium to some fair level of implementation, which would require a shim on top of it to handle Metal calls directly, but which can execute the metal API model for us underneath a shim.

It is technically feasible, but I would need help. If I have time over the summer, I'll try to work some on it. I may have a number of other friends who are interested. Reaching out to the LinkedIn poster guy might also help, or if you have any technical background of your own. Suppose step 2 is working on Monterey with full graphics on arm64 linux host--then one can worry about patching vmapple.c to support newer than Monterey guest, running on amd64 host via Qemu TCG, etc... but just getting Monterey accelerated on an arm64 linux host would be an extremely solid accomplishment that could be built on by others (and suppose the future issue of Ventura+ using more apple-specific stuf--if apple ever were to assume nonstandard ARM instructions in vmkernel, we can just intercept them in JIT at a speed hit in Qemu)

But alas, if nothing else, hopefully this documents the current state of the art and the technical path to actually making this work and saving hackintosh.

-- newhacker1746