macOS arm64 can run on non-Apple hardware using a relatively lightly changed KVM (and the Qemu-side changes are even less intensive than the iOS on Qemu project). However, it doesn't come without compromises on most hardware.
What I can enumerate as risk factors for running macOS arm64 in a VM:
- ARMv8.1 atomics are mandatory. This excludes Cortex-A72 devices, like the RPi4, and earlier generations.
- 16KB page support are mandatory, excludes the RPi4 and other devices too.
- Rosetta uses an MSR to switch the memory model, this makes x86 threads have to all run only at one core at once on Arm CPUs where there isn't a stronger memory model.
Notably, some Arm server CPUs provide TSO, making this a non-issue, and Nvidia's Tegra Xavier CPUs provide sequential consistency, making it a non-issue.
- PAC, not a big risk factor, trap once and then patch to the non-PAC variant at worst for instructions that aren't in the NOP space.
- FP16/dotproduct: provided in HW from quite some other manufacturers, and even when it isn't, you could feasibly emulate those fast enough.
On GPUs, Metal paravirtualization exists in macOS 11, maybe would be better to target that for reverse-engineering purposes.
Even if you give up on Rosetta, there’s all the other MSRs you’ll need to patch–there’s not a huge number of these, but since EL0 has direct access to at least one of these you can’t just patch the kernel.
> PAC, not a big risk factor, trap once and then patch to the non-PAC variant at worst for instructions that aren't in the NOP space.
You know, I don’t think Apple really uses the backwards-compatible encodings at all. Probably since they don’t need to?
> Even if you give up on Rosetta, there’s all the other MSRs you’ll need to patch–there’s not a huge number of these, but since EL0 has direct access to at least one of these you can’t just patch the kernel.
APRR can only remove permissions, not add them. As such, it can be stubbed out. The other MSRs are tunables for CPU errata workarounds, which can just be stubbed too.
> You know, I don’t think Apple really uses the backwards-compatible encodings at all. Probably since they don’t need to?
You just need to trap once for each time you see them and then patch it there.
How long before Apple has even 1 proprietary extension to arm64 without which macOS won't run? As soon as hw without that extension is EoL, no more hackintoshes.
What I can enumerate as risk factors for running macOS arm64 in a VM:
- ARMv8.1 atomics are mandatory. This excludes Cortex-A72 devices, like the RPi4, and earlier generations.
- 16KB page support are mandatory, excludes the RPi4 and other devices too.
- Rosetta uses an MSR to switch the memory model, this makes x86 threads have to all run only at one core at once on Arm CPUs where there isn't a stronger memory model. Notably, some Arm server CPUs provide TSO, making this a non-issue, and Nvidia's Tegra Xavier CPUs provide sequential consistency, making it a non-issue.
- PAC, not a big risk factor, trap once and then patch to the non-PAC variant at worst for instructions that aren't in the NOP space.
- FP16/dotproduct: provided in HW from quite some other manufacturers, and even when it isn't, you could feasibly emulate those fast enough.
On GPUs, Metal paravirtualization exists in macOS 11, maybe would be better to target that for reverse-engineering purposes.