|
|
|
|
|
|
by derefr
1758 days ago
|
|
|
> making running macOS on any other ARM CPU quite impractical without deep hacks Presuming those other 2025-era ARM CPUs have standardized virtualization extensions, macOS would probably be best run through a hardware-accelerated hybrid emulator that interprets, rather than executes, the non-supported instructions. (Think Linux-aarch64 running qemu-kvm.) “Hackintoshing” in the sense of needing to write macOS drivers for Apple-unsupported hardware/peripherals would still exist in that world, as people would want to pass hardware (like the GPU!) through to the VM for performance. Though the construction of these drivers might be easier than today, as for peripherals that are just too hard to get macOS itself to support, hardware-abstracted peripheral drivers could be written instead (or even reused from VM software like VMWare Fusion!) |
|
|
If only ARM virtualization could do that - it would've made my life much easier when writing the m1n1 hypervisor.
There is no facility for intercepting and trapping unsupported instructions in EL0/1 into EL2. The undefined instruction exception goes straight to the guest. I had to hijack this for early bringup debugging and ended up patching the guest's exception table, but needless to say that isn't terribly nice...
ARM macOS requires a GPU (WindowServer won't run without one), which means supporting Metal. So not only do you need to write a GPU driver, you need to write a GPU driver that supports Metal. Apple support paravirtualized GPUs... by passing through Metal, as I understand it. That's only easy if your host OS is macOS.