What are everyone’s thoughts on the future of Hackintoshes now that Apple is switching to ARM?
Some people suggest that Apple will do some special custom hardware in the CPU that will mean Hackintoshes are impossible, but any hardware can be emulated in software, so it then becomes a performance issue. Maybe your ML workloads will suck compared to Apple hardware, for instance.
I think the biggest danger is that Apple ARM hardware doesn't support non-Apple GPUs, but even then some enterprising hacker will probably accept the challenge and enable a Linux driver bridge or the like.
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.
You can take the iPhone CPU and make it into an ARM CPU for a laptop that can compete with Intel and AMD (somewhat) easily. That same architecture is in no way reflective of what people expect out of a workstation. Unless Apple is going to start running all of their own internal workloads ("Apple Cloud") on their own CPUs, I don't see it happening. And in order to do that, they're going to have to get mainline OS support for it, which again is a very different path to market than doing everything in-house with OSX.
Same architecture but this is all about the silicon and what extra hardware accelerated features can apple build into the OS by adding modules to their SoC. That will have little to do with the fact that it's using the ARM architecture in relation to getting those features to work on non Apple Silicon devices.