It will. Because Apple is deprecating classic kernel extensions, and an alternate hypervisor cannot be made without a classic kernel extension. I highly doubt if any company like VMware or Parallel will invest in a technology that Apple will stop support in the future. We have to wait for Apple for now, as macOS is Apple's the walled garden.
It won't. Because Apple's Hypervisors is not used in the vast majority of cloud services shops. Those shops won't be running the M1. It is the Hypervisor on ARM server implementations I'm talking about there. The context here is talking about AMD/NVidia drivers coming up on
Windows . M1 doesn't primarily define the Windows ARM space at all.
Alternative Hypervisors (like ESXi and the rest of VMware's product catalog besides Fusion (i.e., where the real money is) ) on M1 are in the same sinking boat as any other operating system besides macOS. Apple isn't allowing them to boot onto the RAW hardware. [ There are some hacks that rely on jailbreak hacks but those are likely to close on future iterations of M-series Macs. That isn't a 'business model'. ] None of the ARM server CPU vendors are trying to limit their CPU package to just one OS. Multiple Hypervisors will probably show up in that space. Vastly different ecosystem dynamics.
Apple will/could eventually get some trickle down, upside side-effect while being 'closed' because the other options are open.
Don't really need a classic kernel extension here. The kernel just need to 'ignore' the device while delegating the driver work to the guest OS. Apple's new System extension work by leveraging IOMMU. That is the same basic core mechanism that is needed here. However, the mapping needed to be done is different. System extensions map certain specially designated processes that are "in between" kernel and regular user address space into a narrow subset of kernel address space. What is needed here is to not map the device into the active kernel space at all , but solely into a guest kernel space. it is still basically an IOMMU mapping. However, that isn't going to follow the same object model design or basic implementation of Apple has now. Making that work stably and securely is real work that just isn't being done now. ( e.g., once that device is delegated to the guest OS the other kernel code and user space apps shouldn't be able to get to it either. That is not what System extensions generally do. ).
What Apple is doing is a 'minimal work for them' hypervisor. It isn't a Type 1 ( it is type 2) and they aren't particularly trying to be in the "1.5" zone. It is perhaps closer to being a toolkit to building a hypervisor than actually being one. (e.g. xhyve is "byhve" build on top the framework
https://wiki.freebsd.org/bhyve#Q:_Could_bhyve_be_ported_to_other_operating_systems.3F
xhyve, a lightweight OS X virtualization solution. Contribute to machyve/xhyve development by creating an account on GitHub.
github.com
)
But yes, because Apple is kicking everyone out of the kernel and giving the hypervisor framework as the only path to constructing a hypervisor.... if they don't provide the tools for pass-thru in the over system library framework then the resulting hypervisors will be limited. However, if Apple is going to allow thunderbolt and eventually have a Mac Pro with at least some slots, their framework need to be flushed out over time. Especially, with the whole "virtualization is only path to other OS" dogma. This mapping extension may not make the 'add list" though if the cards/devices Apple completely is very small unit volume in those internal/external slots.
They don't need to extend the kernel, but the kernel just need to do the set up assignment work and then get out of the way. No need for 3rd parties to do the tweak kernel if Apple simply does the delegation work. It is already delegating for System extensions. ( the need for the general concept of drivers didn't drop to zero. ). This is just another "flavor" of delegation. Kernel extensions disappearing isn't completely a "show stopper".
