4 ms·
Slightly tangential, but has anyone virtualized ARM macOS on x86-64?
by heavyset_go 2y ago
Slightly tangential, but has anyone virtualized ARM macOS on x86-64?
- 3abiton 2y agoYou should look into the hackintosh project.
- aspenmayer 2y agohttps://dortania.github.io/OpenCore-Legacy-Patcher/ https://dortania.github.io/OpenCore-Legacy-Patcher/
- fl0id 2y agoBut that’s not arm on x86 is it? My understanding was that it ‘just’ enables things to work on unsupported intel macs, by enabling stuff that still works on newer Intel Macs.
- aspenmayer 2y agoIt’s complicated, but you have the right intuition about it. OCLP re-inserts drivers removed by Apple and patches the OS to enable functionality that doesn’t rely on hardware verification or ARM hardware. According to the devs, that’s about all they are currently able to do with current approaches. UTM might do what you want but likely not on x86. https://mac.getutm.app/ https://mac.getutm.app/ > Virtualize macOS as well. > Run multiple instances of macOS on your Apple Silicon Mac with UTM. This can be useful for developers as well as security conscious users. > Note that macOS VM support is limited to ARM based Macs running macOS Monterey or higher.
- tonyedgecombe 2y ago>or ARM hardware What is ARM hardware in this case? Did you mean the T2 processor on Intel Macs?
- aspenmayer 2y agoI mean both T2 (which I meant by hardware security) and ARM hardware (which means that it relies on either the ARM CPU itself or the way it functions or is implemented). Features like iPhone mirroring apparently rely on hardware support on macOS.
- amarshall 2y agoHackintosh currently has no way of running ARM-based macOS, so it is of no help here.
- aliher1911 2y agoYou can try to virtualize generic ARM in qemu and see that it won't reach Raspberry Pi performance. Recent versions should have it available out of the box afaik. Virtualizing Mn cpus would be even less useful.
- grishka 2y agoYou can't. The term "virtualize" is generally used to mean running an OS via hardware virtualization, where your host CPU natively runs its code but forwards all I/O to a hypervisor. You can only do that with an OS built for the same CPU architecture as your host system. For everything else, like running ARM software on x86 (and vice versa), you'll have to resort to emulation, which involves either interpreting the code or dynamically recompiling it. By definition, you can emulate anything on anything else (someone recently booted Linux for MIPS on an Intel 4004, the first ever microprocessor), but the performance might be a problem.
- amarshall 2y agoTL;DR: emulating any ARM binaries on x86_64 via QEMU is so slow that it is unusable for any general use. This is also less of a QEMU problem and more just that ARM does not emulate well on x86_64 due to their designs.
- userbinator 2y agoI have tried emulating ARM Windows on x86 with QEMU. It is fast enough to see whether something works and not much more (imagine Windows 11 on a 400MHz equivalent processor to understand what the performance was like --- and the host was a fairly recent Intel i7.) ARM Linux is close to usable, however.
- grishka 2y agoIt feels like it's just not possible in general to emulate the full instruction set of any CPU with an MMU with an acceptable performance to run modern software. QEMU running Windows for x86 on an M1 isn't very fast either. Only emulating the portion of the instruction set available from the userspace is another story though. At least the way Apple does it with Rosetta and Microsoft with whatever their thing is called, you don't even notice that an app is running under emulation. The only giveaway is that it takes a noticeable time to start for the first time while the code is being translated. It's truly impressive.