5 ms·

Is virtualizing aarch64 macos via qemu on aarch64 Linux within the realm of possibility? I know it can be done for x86-64, but would be pretty cool if an aarch6

Is virtualizing aarch64 macos via qemu on aarch64 Linux within the realm of possibility? I know it can be done for x86-64, but would be pretty cool if an aarch64 kvm hackintosh would be possible. I have an Nvidia Jetson AGX and honeycomb lx2 which in theory could be up to the task.

mod50ack 4y ago
There are additional instructions only available on Apple chips beyond the aarch64 standard, so I don't think that this could be done in hardware (someone correct me if I'm wrong because this isn't my area) Of course it's possible in software in principle but obviously that would be awful.
- userbinator 4y ago
  Of course it's possible in software in principle but obviously that would be awful. The Hackintosh community emulated SSE2/3 to allow OS X to run on CPUs that didn't have those extensions, and AFAIK it worked reasonably well: http://www.tutilapia.com/2011/11/a-little-about-hackintosh-iatkos.html http://www.tutilapia.com/2011/11/a-little-about-hackintosh-i...
  - mod50ack 4y ago
    Then it may be possible. Of course pure SW emulation would be possible but very slow, though.
  - trollied 4y ago
    That’s all well & good, but it’s a completely different game when you’ve got custom secure enclaves & “AI” blocks to deal with.
- g_p 4y ago
  Apple has their own custom conventions and ABI (https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...). I believe you are right that they have their own custom instructions too. The asahi Linux project has good documentation on their wiki about the hardware. Also important here is the bespoke ASIC functionality on their CPUs - as it's a system on chip, you'll likely need to emulate the full SoC, including all the peripherals the system expects to be there. Unlike x86_64, ARM isn't really designed to do device discovery on extensible buses in the same way. Your peripherals should all be in the same place, many being on the chip on internal interconnects. Emulating anything would be possible with enough effort. But you'd likely need to emulate a whole host of extra bespoke silicon functionality on the SoC to get it working. For example, given every ARM Mac has a hardware neural engine, you might find unmodified Mac OS assumes it's there and usable for core functionality (or does so in future). It would probably be a lot of work to emulate all of the extra SoC stuff to the point you could boot the OS unmodified. But nothing is impossible - I think iOS has been run in third party emulators etc.
  - martinald 4y ago
    Yeah, agreed. I think of every ARM SoC as more like its entire own architecture, for OS compat purposes. A Raspberry Pi SoC will require an entirely different level of compatibility to an M1 Mac, or a Snapdragon based Chromebook. I think we've been somewhat spoilt by x86 and how easy loads of different machines will boot the same OS image. It's really really different in ARM land.
  - comex 4y ago
    ABI, which calling conventions are one part of, only affects how different pieces of code within the operating system talk to each other. It’s not uncommon to customize it - for instance, Windows does too. [1] Having a custom ABI does not present any obstacle to emulation. The rest of what you said is right, though. [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170 https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi...
  - qubex 4y ago
    To ease execution of x86₆₄ applications on Apple Silicon the Apple processor team implemented the x86 memory model with a series of additional experiences.
- my123 4y ago
  Those aren't an issue really. macOS VMs eschew most apple extensions anyway (no AMX there for example). The big roadblock that we've hit is that arm64 macOS has no software rasteriser for rendering the GUI. The result is that unless you implement Metal and the paravirtualised GPU infrastructure, you're stuck in console mode.
  - kitsunesoba 4y ago
    > The big roadblock that we've hit is that arm64 macOS has no software rasteriser for rendering the GUI. The result is that unless you implement Metal and the paravirtualised GPU infrastructure, you're stuck in console mode. And this has been just as much of an issue for virtualizing x86 macOS… although it does have a software rasterizer, it's almost unusably slow. The only way you're going to get decent performance with that is with passthrough of a GPU that macOS has drivers for (which for modern GPUs, means some Radeon 500 series, Radeon 5000/6000 series, or Intel iGPU up through Coffee Lake). Since the early 2000s, real Macs have practically never been configured in such a way that there's no usable GPU, and so the software rasterizer never got any attention since it's an absolute-last-resort fallback. With ARM Macs, all models have some form of usable GPU available (presumably, even the forthcoming M-series cheesegrater tower will have a few GPU cores in its SoC) and they don't care to support virtualization on anything but macOS so they dropped the rasterizer entirely.
tmccrary55 4y ago
I'd be way more excited about a stable and fully featured Linux port to M1+
- userbinator 4y ago
  That appears to be in progress: https://news.ycombinator.com/item?id=25649719 https://news.ycombinator.com/item?id=25649719
  - astrange 4y ago
    Lot of negativity in that comment section.
userbinator 4y ago
It's probably about as possible as emulating anything else with qemu, which is to say, definitely possible after some more development effort. Some interesting discussions on HN from when the M1 first came out: https://news.ycombinator.com/item?id=25064593 https://news.ycombinator.com/item?id=25064593 https://news.ycombinator.com/item?id=24071371 https://news.ycombinator.com/item?id=24071371
thejosh 4y ago
I fooled around with this for a weekend, learnt a lot about qemu and friends. So there is this: https://blogs.blackberry.com/en/2021/05/strong-arming-with-macos-adventures-in-cross-platform-emulation https://blogs.blackberry.com/en/2021/05/strong-arming-with-m... And there is also work around getting iOS to boot, which could pave the way for future work. https://github.com/sickcodes/Docker-eyeOS https://github.com/sickcodes/Docker-eyeOS
deleted 4y ago
[deleted]

mod50ack 4y ago

There are additional instructions only available on Apple chips beyond the aarch64 standard, so I don't think that this could be done in hardware (someone correct me if I'm wrong because this isn't my area) Of course it's possible in software in principle but obviously that would be awful.

userbinator 4y ago
Of course it's possible in software in principle but obviously that would be awful. The Hackintosh community emulated SSE2/3 to allow OS X to run on CPUs that didn't have those extensions, and AFAIK it worked reasonably well: http://www.tutilapia.com/2011/11/a-little-about-hackintosh-iatkos.html http://www.tutilapia.com/2011/11/a-little-about-hackintosh-i...
- mod50ack 4y ago
  Then it may be possible. Of course pure SW emulation would be possible but very slow, though.
- trollied 4y ago
  That’s all well & good, but it’s a completely different game when you’ve got custom secure enclaves & “AI” blocks to deal with.
g_p 4y ago
Apple has their own custom conventions and ABI (https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://developer.apple.com/documentation/xcode/writing-arm6...). I believe you are right that they have their own custom instructions too. The asahi Linux project has good documentation on their wiki about the hardware. Also important here is the bespoke ASIC functionality on their CPUs - as it's a system on chip, you'll likely need to emulate the full SoC, including all the peripherals the system expects to be there. Unlike x86_64, ARM isn't really designed to do device discovery on extensible buses in the same way. Your peripherals should all be in the same place, many being on the chip on internal interconnects. Emulating anything would be possible with enough effort. But you'd likely need to emulate a whole host of extra bespoke silicon functionality on the SoC to get it working. For example, given every ARM Mac has a hardware neural engine, you might find unmodified Mac OS assumes it's there and usable for core functionality (or does so in future). It would probably be a lot of work to emulate all of the extra SoC stuff to the point you could boot the OS unmodified. But nothing is impossible - I think iOS has been run in third party emulators etc.
- martinald 4y ago
  Yeah, agreed. I think of every ARM SoC as more like its entire own architecture, for OS compat purposes. A Raspberry Pi SoC will require an entirely different level of compatibility to an M1 Mac, or a Snapdragon based Chromebook. I think we've been somewhat spoilt by x86 and how easy loads of different machines will boot the same OS image. It's really really different in ARM land.
- comex 4y ago
  ABI, which calling conventions are one part of, only affects how different pieces of code within the operating system talk to each other. It’s not uncommon to customize it - for instance, Windows does too. [1] Having a custom ABI does not present any obstacle to emulation. The rest of what you said is right, though. [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170 https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi...
- qubex 4y ago
  To ease execution of x86₆₄ applications on Apple Silicon the Apple processor team implemented the x86 memory model with a series of additional experiences.
my123 4y ago
Those aren't an issue really. macOS VMs eschew most apple extensions anyway (no AMX there for example). The big roadblock that we've hit is that arm64 macOS has no software rasteriser for rendering the GUI. The result is that unless you implement Metal and the paravirtualised GPU infrastructure, you're stuck in console mode.
- kitsunesoba 4y ago
  > The big roadblock that we've hit is that arm64 macOS has no software rasteriser for rendering the GUI. The result is that unless you implement Metal and the paravirtualised GPU infrastructure, you're stuck in console mode. And this has been just as much of an issue for virtualizing x86 macOS… although it does have a software rasterizer, it's almost unusably slow. The only way you're going to get decent performance with that is with passthrough of a GPU that macOS has drivers for (which for modern GPUs, means some Radeon 500 series, Radeon 5000/6000 series, or Intel iGPU up through Coffee Lake). Since the early 2000s, real Macs have practically never been configured in such a way that there's no usable GPU, and so the software rasterizer never got any attention since it's an absolute-last-resort fallback. With ARM Macs, all models have some form of usable GPU available (presumably, even the forthcoming M-series cheesegrater tower will have a few GPU cores in its SoC) and they don't care to support virtualization on anything but macOS so they dropped the rasterizer entirely.

tmccrary55 4y ago

I'd be way more excited about a stable and fully featured Linux port to M1+

userbinator 4y ago
That appears to be in progress: https://news.ycombinator.com/item?id=25649719 https://news.ycombinator.com/item?id=25649719
- astrange 4y ago
  Lot of negativity in that comment section.

userbinator 4y ago

It's probably about as possible as emulating anything else with qemu, which is to say, definitely possible after some more development effort. Some interesting discussions on HN from when the M1 first came out: https://news.ycombinator.com/item?id=25064593 https://news.ycombinator.com/item?id=25064593 https://news.ycombinator.com/item?id=24071371 https://news.ycombinator.com/item?id=24071371

thejosh 4y ago

I fooled around with this for a weekend, learnt a lot about qemu and friends. So there is this: https://blogs.blackberry.com/en/2021/05/strong-arming-with-macos-adventures-in-cross-platform-emulation https://blogs.blackberry.com/en/2021/05/strong-arming-with-m... And there is also work around getting iOS to boot, which could pave the way for future work. https://github.com/sickcodes/Docker-eyeOS https://github.com/sickcodes/Docker-eyeOS

deleted 4y ago

[deleted]