The fact that he even got that far with emulating what is essentially completely undocumented hardware is a very good sign, adding the rest of the hardware to QEMU might not be as hard as initially thought.
This approach will help with none of these
Don't underestimate the community -- a lot of Hackintosh (and emulation) stuff is done for the "just because I can" reasons, and getting a fully emulated ARM Mac working enough for any sort of actual use would be a huge win even if it's slower than their hardware and not 100% complete (just like Hackintoshes usually are.)
Not surprised given their attempt to run AIX on QEMU as well. That's slightly more documented but still a pain to do - as it requires specific versions of AIX(7.2 TL3 SP1/7.1 TL5 SP5).
> The fact that he even got that far with emulating what is essentially completely undocumented hardware is a very good sign, adding the rest of the hardware to QEMU might not be as hard as initially thought.
I'm less convinced—it sounds like he was largely reusing the setup that can semi-boot iOS (which is of course also totally undocumented, but has had many years to be studied.)
It's still a cool accomplishment, I just don't think it necessarily portends great things.
> Besides, Hackintoshes are often built when Apple’s own hardware isn’t fast enough; in this case, Apple’s ARM processors are already some of the fastest in the industry.
They are also used when one wants more cores than are possible on Apple hardware. If you want a build engine for a medium to large sized compiled language project, Apple has no options that make economic sense, since a Ryzen Threadripper will beat everything else hands down. The same is true of every other embarrassingly parallel, linearly-scaling compute problem.
In such cases, the "speed" of Apple's own silicon doesn't help at all.
Hackintoshes from my experience are usually built as a low cost hobbyist alternative. Most people earning a living from a Mac will sacrifice speed to have stability and support.
Plenty of people who want MacOS but cannot afford the official Mac will use it instead.
This speed advantage won’t apply when emulating Apple silicon on an x86-64 CPU, as discussed here.
Emulating ARM on x86-64 is doable, but it has dramatically more overhead. It’s doubtful that a high core count would be enough to overcome this relative to just using Apple silicon.
Let’s wait the Apple Silicon Mac Pro. I think they are all in on this fastest chip race thing, with deep pockets, high paying customers and scale behind them.
I noticed he was using -d unimp on the qemu command line so qemu should print unimplemented features when it encounters them. (Of course that only prints them, you'll still need to research / reverse engineer to discover what they are).
This is some very cool hacking, but I’m more interested in knowing how Apple Silicon will run x86 Windows and Linux stuff. Can virtualization software get help from Rosetta 2? Or is QEMU and similar the best we can hope for?
_If you really need to_, Huawei provides the ExaGear Server translator for Linux at https://www.huaweicloud.com/kunpeng/software/exagear.html , which allows to run x86 and x86_64 apps on an arm64 Linux system, including Docker containers for their customers. That translator works pretty well in most cases.
Note however that you need to create a Huawei account to download this.
For Windows guests:
Run arm64 Windows, the JITs to run x86(_64) apps are included with the OS.
Apple TV 4K uses the A10X, which is ARMv8.0. That's so old that it even pre-dates the true atomics instructions (which are intro'd in 8.1-A). So it'll have to be a pretty heavyweight JIT to adapt ARMv8.3 code to that baseline.
For Apple A11 though, going from 8.3 -> 8.2 is much easier... and doable through a patch on fault method.
Incredible. Emulating AppleSilocon before they even announced it.
Does anybody know where one can learn about how these people approach and learn about the inner workings of what is essentially a black box from the outside?
userbinator|5 years ago
This approach will help with none of these
Don't underestimate the community -- a lot of Hackintosh (and emulation) stuff is done for the "just because I can" reasons, and getting a fully emulated ARM Mac working enough for any sort of actual use would be a huge win even if it's slower than their hardware and not 100% complete (just like Hackintoshes usually are.)
m463|5 years ago
https://youtu.be/86XqF5dqjYc
pretty cool
I've been thinking about resurrecting my machines with older versions of osx - I'll have to figure out how to boot say 10.11 or 10.12
birdyrooster|5 years ago
cmxch|5 years ago
chongli|5 years ago
Wowfunhappy|5 years ago
I'm less convinced—it sounds like he was largely reusing the setup that can semi-boot iOS (which is of course also totally undocumented, but has had many years to be studied.)
It's still a cool accomplishment, I just don't think it necessarily portends great things.
unknown|5 years ago
[deleted]
PaulDavisThe1st|5 years ago
They are also used when one wants more cores than are possible on Apple hardware. If you want a build engine for a medium to large sized compiled language project, Apple has no options that make economic sense, since a Ryzen Threadripper will beat everything else hands down. The same is true of every other embarrassingly parallel, linearly-scaling compute problem.
In such cases, the "speed" of Apple's own silicon doesn't help at all.
gogopuppygogo|5 years ago
Plenty of people who want MacOS but cannot afford the official Mac will use it instead.
PragmaticPulp|5 years ago
Emulating ARM on x86-64 is doable, but it has dramatically more overhead. It’s doubtful that a high core count would be enough to overcome this relative to just using Apple silicon.
tambourine_man|5 years ago
als0|5 years ago
Does anyone know what these instructions are? And could you not trap and emulate them if the hypervisor detects an invalid instruction?
qiqitori|5 years ago
saagarjha|5 years ago
rwmj|5 years ago
m3nu|5 years ago
1: https://wiki.debian.org/Arm64Port
Maursault|5 years ago
Rosetta 2 != Rosetta
We practice all day for accuracy.
mshockwave|5 years ago
tambourine_man|5 years ago
my123|5 years ago
_If you really need to_, Huawei provides the ExaGear Server translator for Linux at https://www.huaweicloud.com/kunpeng/software/exagear.html , which allows to run x86 and x86_64 apps on an arm64 Linux system, including Docker containers for their customers. That translator works pretty well in most cases.
Note however that you need to create a Huawei account to download this.
For Windows guests:
Run arm64 Windows, the JITs to run x86(_64) apps are included with the OS.
The VHDX for virtual machine use can be downloaded from https://www.microsoft.com/en-us/software-download/windowsins...
floatboth|5 years ago
my123|5 years ago
As such, might be a better approach to start with the set of devices exposed by Qemu. :-)
fgblanch|5 years ago
my123|5 years ago
For Apple A11 though, going from 8.3 -> 8.2 is much easier... and doable through a patch on fault method.
protoman3000|5 years ago
Does anybody know where one can learn about how these people approach and learn about the inner workings of what is essentially a black box from the outside?
saagarjha|5 years ago
Koshkin|5 years ago
octotoad|5 years ago
ExcavateGrandMa|5 years ago
[deleted]
ngcc_hk|5 years ago