Booting a macOS Apple Silicon Kernel in QEMU(worthdoingbadly.com) |
Booting a macOS Apple Silicon Kernel in QEMU(worthdoingbadly.com) |
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.)
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
https://www.nicksherlock.com/2020/04/installing-macos-catali...
one cool thing is - once you have it installed, you can clone it freely and even remote log into several at once.
I believe they even figured out how to run them on those 32-core or 64-core amd threadrippers.
Not long after I got a relatively successful hackintosh going (read: accelerated graphics and working audio), which, besides Linux, helped brew my respect for Unix, BSD, and unique macOS internals.
Altogether it lead me to purchase roughly 5 Macs over the years. I recently got back into it for fun, and the scene is thriving. Will be interesting to see what happens post-AS.
Doing things for the heck of it is, for some reason, a great motivator and educator.
Add: actually never say never. Consoles with custom GPUs have been very successfully emulated. So maybe someday.
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.
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.
Does anyone know what these instructions are? And could you not trap and emulate them if the hypervisor detects an invalid instruction?
Rosetta 2 != Rosetta
We practice all day for accuracy.
_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...
Why would I want to use a (presumably) closed-source solution from Huawei whose documentation is only in Chinese, when I could instead use a well-known open source project with plentiful documentation in English?
As such, might be a better approach to start with the set of devices exposed by Qemu. :-)
For Apple A11 though, going from 8.3 -> 8.2 is much easier... and doable through a patch on fault method.
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?
I guess Jonathan Levin’s Books should then be mentioned here.
However, that then leads to the question how Levin reversed this black box.
Plenty of people who want MacOS but cannot afford the official Mac will use it instead.
I could afford to buy hardware from Apple, but why would I when the cost/performance ratio for an embarrasingly parallel compute task like compiling is so much worse?
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.
Then again maybe they just have a good JVM and that solves most of the problem for Android apps?
I've spent a lot of time on this. With QEMU, the performance gap is huge right now.
I have several ARM/QEMU virtual machines running on my AMD virtualization server, but the emulation overhead makes everything painfully slow, even when assigning 20+ cores to the VM. I picked up an 8GB Raspberry Pi because it's often faster to run a workload on the Raspberry Pi than even the many-core AMD emulated system.
The emulation overhead across architectures is huge with QEMU.
So, uh, the slowdown seems pretty bad to me.
You could of course use the software renderer—I'd guess that probably still exists on Apple Silicon Macs for safe mode and such—but it wouldn't be pleasant...
Edit: Well, anyone besides nVidia, I suppose. But they're a big company, not a Hackintosh side project.
PowerPC AS only requires 1 tag bit for every 16 bytes. (1 tag bit for every 128 data bits, 1 tag byte for every 128 data bytes, etc.) That's 8MB of tags for every 1GB of memory. So the overhead isn't massive [1].
Do recent IBM i versions still rely on hardware enforcement of tagged memory?
Even if QEMU does support odd-sized virtual sectors, given the integral support for logical partitioning included within modern IBM i releases, various system management and RAS features, etc., I'd be entirely unsurprised to learn that significant firmware support isn't also required to boot the OS at all, regardless of I/O device support.
In which case, you'd either need to reimplement a significant bit of IBM firmware functionality from scratch, or else you'd need to emulate POWER system hardware convincingly enough to fool (possibly hacked) authentic IBM firmware.
Finally, given that AFAIK IBM has never sold unbundled licenses for IBM i (or OS/400), the only potentially legal way to do any of this would be to run QEMU a POWER system already licensed to run IBM i (no technical problem, as all recent POWER systems have excellent Linux support).
*Where, by "similar", I'm thinking of virtual disks used by virtual instances running within an existing IBM i instance, which wouldn't be helpful here.
FEX is an experimental open-source solution at https://github.com/FEX-Emu/FEX, but it's still in heavy development.
They discontinued the product beginning of 2019 and presumably? got bought by Huawei.