Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Booting a macOS Apple Silicon Kernel in QEMU

worthdoingbadly.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Booting a macOS Apple Silicon Kernel in QEMU

#41

Post by monocasa »

skissane wrote: post #33
cmxch wrote: post #18

Earlier quoted context omitted.

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).

I'd really like to see someone run IBM i (formerly known as OS/400) on QEMU. Has anyone tried?

Even the PowerPC version of OS/400 uses custom instructions pretty heavily. It's a tagged memory architecture with another hidden 65th bit. I don't think QEMU has support for that, and it'd be extremely slow to emulate.

Re: Booting a macOS Apple Silicon Kernel in QEMU

#42

Post by skissane »

monocasa wrote: post #41
skissane wrote: post #33

Earlier quoted context omitted.

I'd really like to see someone run IBM i (formerly known as OS/400) on QEMU. Has anyone tried?

Even the PowerPC version of OS/400 uses custom instructions pretty heavily. It's a tagged memory architecture with another hidden 65th bit. I don't think QEMU has support for that, and it'd be extremely slow to emulate.

I don't believe QEMU emulates tagged memory on POWER, but it does emulate tagged memory on ARM (MTE), so there is no reason why it couldn't be added.

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?

[1] https://www.devever.net/~hl/ppcas

Re: Booting a macOS Apple Silicon Kernel in QEMU

#43

Post by my123 »

skissane wrote: post #37
my123 wrote: post #32

Earlier quoted context omitted.

For Linux guests: _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: Ru…

Why use ExaGear, why not just use qemu-user-static? 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?

It's because Qemu is several orders of magnitude slower, it's not even in the same class of solution.

FEX is an experimental open-source solution at https://github.com/FEX-Emu/FEX, but it's still in heavy development.

Re: Booting a macOS Apple Silicon Kernel in QEMU

#44

Post by samtheprogram »

birdyrooster wrote: post #3
userbinator wrote: post #2

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…

It might not be fast or pretty but I agree there will be emulation. Anyone remember PearPC?

I remember running (I think) Jaguar on PearPC; mind you, Leopard was probably out by that point, I just had old disks handed down to me and no actual Macintosh. It was a lot of fun digging into the OS like that, especially at a young age, but definitely slow considering it’s emulating another instruction set.

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.

Re: Booting a macOS Apple Silicon Kernel in QEMU

#45

Post by jeswin »

chongli wrote: post #36
userbinator wrote: post #2

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…

Oh wow. Imagine a Hackintosh Raspberry Pi! Now that would be a cheap way to run macOS!

I know you said this sarcastically. The custom GPU is going to be a huge roadblock to get anything graphical to render. Probably never going to happen.

Add: actually never say never. Consoles with custom GPUs have been very successfully emulated. So maybe someday.

Re: Booting a macOS Apple Silicon Kernel in QEMU

#46

Post by muterad_murilax »

chongli wrote: post #36
userbinator wrote: post #2

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…

Oh wow. Imagine a Hackintosh Raspberry Pi! Now that would be a cheap way to run macOS!

I suggested the same thing the other day and got downvoted...

Re: Booting a macOS Apple Silicon Kernel in QEMU

#47

Post by jasomill »

skissane wrote: post #42
monocasa wrote: post #41

Earlier quoted context omitted.

Even the PowerPC version of OS/400 uses custom instructions pretty heavily. It's a tagged memory architecture with another hidden 65th bit. I don't think QEMU has support for that, and it'd be extremely slow to emulate.

I don't believe QEMU emulates tagged memory on POWER, but it does emulate tagged memory on ARM (MTE), so there is no reason why it couldn't be added. 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 enforceme…

IBM i tends to be picky about disks, as well. At least as of a couple years ago, the only way to use local disks with standard 512-byte or 4096-byte sector sizes was through VIOS or similar* storage virtualization mechanisms, so unless QEMU supports 520- or (4096+mumble)-byte virtual SAS disks, you also need to emulate enough of the IBM POWER hypervisor architecture to support running VIOS (IBM's AIX-derived virtual I/O appliance) concurrently in a separate logical partition within the same QEMU VM.

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.

Re: Booting a macOS Apple Silicon Kernel in QEMU

#48

Post by skissane »

my123 wrote: post #43
skissane wrote: post #37

Earlier quoted context omitted.

Why use ExaGear, why not just use qemu-user-static? 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?

It's because Qemu is several orders of magnitude slower, it's not even in the same class of solution. FEX is an experimental open-source solution at https://github.com/FEX-Emu/FEX , but it's still in heavy development.

> Qemu is several orders of magnitude slower, it's not even in the same class of solution

Why? QEMU has a JIT

Re: Booting a macOS Apple Silicon Kernel in QEMU

#49

Post by londons_explore »

jeswin wrote: post #45
chongli wrote: post #36

Earlier quoted context omitted.

Oh wow. Imagine a Hackintosh Raspberry Pi! Now that would be a cheap way to run macOS!

I know you said this sarcastically. The custom GPU is going to be a huge roadblock to get anything graphical to render. Probably never going to happen. Add: actually never say never. Consoles with custom GPUs have been very successfully emulated. So maybe someday.

You don't have to emulate the hardware directly. Since apples kernel is opensource, there's a good chance one could write a kernel driver for another GPU offering a sufficiently compatible interface. Nearly all GPU code will have software rendering fallbacks too, so the driver might just be enough to trigger those fallbacks.

Re: Booting a macOS Apple Silicon Kernel in QEMU

#50

Post by my123 »

skissane wrote: post #48
my123 wrote: post #43

Earlier quoted context omitted.

It's because Qemu is several orders of magnitude slower, it's not even in the same class of solution. FEX is an experimental open-source solution at https://github.com/FEX-Emu/FEX , but it's still in heavy development.

> Qemu is several orders of magnitude slower, it's not even in the same class of solution Why? QEMU has a JIT

Long story... Qemu's JIT is really not what you want for high performance. TCG is much more geared towards portability as a goal.
Post reply on HN