4 ms·

It's probably 2030 before Intel Mac are no longer usable, which is forever in tech time. ARM seems to be spreading its wings when it comes to high end CPUs at t

It's probably 2030 before Intel Mac are no longer usable, which is forever in tech time. ARM seems to be spreading its wings when it comes to high end CPUs at the moment (for example, the 96 core 4 thread ThunderX3) and it's not a big stretch to think that they will become commodity parts for desktops and servers in the near future, especially if Microsoft follow Apple's lead. Given brisk competition and open ARM licencing is quite likely to give x86 a run for its money and takes substantial market share. 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.

my123 6y ago
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.
- aidenn0 6y ago
  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.
  - my123 6y ago
    For virtualization not an issue, you could feasibly JIT those away.
- saagarjha 6y ago
  > Rosetta uses an MSR to switch the memory model 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?
  - my123 6y ago
    Hello, > 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.

my123 6y ago

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.

aidenn0 6y ago
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.
- my123 6y ago
  For virtualization not an issue, you could feasibly JIT those away.
saagarjha 6y ago
> Rosetta uses an MSR to switch the memory model 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?
- my123 6y ago
  Hello, > 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.