Hacker News Reader

Comment by sircastor | Hacker News Reader

Does this mean Hackintoshes are on their way out? Kexts have been used in that community to maintain support for non Apple hardware.

View on HN

It might mean switching more towards virtualization for Hackintoshes. It's now possible to run a completely, 100% unmodified macOS in qemu/kvm on Linux and use vfio passthrough to place GPUs (mostly Radeon cards) and other PCIe devices into macOS.

Speaking of virtualization, what about using macOS as a VM host? This typically requires kernel mode drivers. It would be awfully inconvenient to not be able to host VMs on a Mac development machine.

It could be this is done by MacOS itself, in a similar manner to Hyper-V on Windows, where you can no longer use VMWare/VirtualBox/etc. Virtualisation is critical to Win 10 security, wouldn't be surprised to see MacOS going in that direction.

New VMware and VirtualBox versions can rely on hyper v platform so you can use them with vbs enabled

Yes, if it worked. But unless they fixed it recently the Virtualbox implementation was super buggy/unusable.

My Windows used to BSOD when running with hyper-v enabled. I disabled it and I'm not going to enable it again anytime soon. VirtualBox works just fine. I don't know why do you think that it's critical to Win 10 security.

And at least on my machine, hybrid sleep doesn't seem to be compatible with Hyper-V, either...

It is in newer versions of Win 10, google Credential Guard and Device Guard.

They'll probably say something about requiring to port your virtualization software to the macOS Hypervisor framework. It has already been the only option for apps distributed via the App Store which want to provide virtualization. Qemu already supports it as the "hvf" backend. I can't speak to what the performance is like.

(there's a bit of history there - a company developed it for a commercial product, Google ended up forking the open source parts for the android emulator which eventually resulted in them contributing it back to qemu upstream).

The Hypervisor framework was released in Yosemite (macOS 10.10). Nice overview of it here <https://www.pagetable.com/?p=764>. There is a (basic) but free implementation xhyve.xyz <https://github.com/machyve/xhyve> which can be used to run various hosts. I know several folks that run Linux so they can use various FPGA development tools to remotely display X windows on the Mac using XQuartz.

But VMWare (probably the best VM software for macOS) doesn't use it, they have their own kexts.

It's maybe the best for macOS, but it's far from being the best VM software. It's full of ugly bugs, especially when trying to script it and use the 'vmrun' tool. It's expensive and support is nearly nonexistent.

You can say you don't like VMware and that's ok. But I remember when I first used it in the 90s and it was absolutely mind blowing. They needed to do slightly crazy things in kernel mode to get that done.

I worry if there is a hypervisor implementation monoculture where everybody is wrapping the same kernel interface, we lose some possibility for a better implementation.

Or if some problem of the future, not VMs, some day requires kernel hacking, but this is artificially locked out. Apple is choosing to not have that innovation happen on their platform. Seems short sighted.

The framework is a relatively light wrapper of the Intel virtualization extensions. The handling of interrupts is definitely not as efficient as it could be, since it doesn't use the professor support for APIC register virtualization and injection of interrupts without exiting to the hypervisor.

(I mentored the Google Summer of Code project that brought the Android emulator's support for Hypervisor.framework to upstream QEMU).

I work on a hypervisor that needs much more than the Intel virtualization extensions. All sorts of registers need to be saved, adjusted, used by virtualization, sampled, and restored. It isn't just the normal guest state that needs to be dealt with.

> Or if some problem of the future, not VMs, some day requires kernel hacking, but this is artificially locked out.

Depending on the use case, you could still compile a custom version of Darwin, if you absolutely need to.

Parallels can use Hypervisor.framework and they didn't axe their entire desktop team a few years ago :)

I'm using Parallels. Support is terrible. Software is ok-ish.

Wow, that's fantastic to hear. I quit messing with Hackintoshes quite a while back, as I just couldn't afford to risk messing around with a daily driver work machine. This could get me back into it.

I know using them for a development house would probably draw Apple's ire, but I really wish they'd license macOS, or maybe a headless macOS for servers/cloud. Doing CI on iOS and macOS apps is a right pain without some kind of build farm. It's a shame like this (https://www.sonnettech.com/product/rackmacmini.html) have to exist (It's not a dig at the product, it's a dig as the situation that created it). I could just imagine spinning up a couple of EPYC systems with macOS VMs to do CI for software for Apple products...

OpenCore loads kexts differently (sorry for lack of technical explanation) so you can keep SIP enalbed, in addition to other advantages over Clover or other methods. More info below.

OpenCore Reference Manual https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/...

OpenCore Vanilla Guide https://khronokernel.github.io/Opencore-Vanilla-Desktop-Guid...

Life, uh, finds a way

Reply on news.ycombinator.com