Until now, I had always thought that the lack of a decent nested virtualization in the current Fusion, etc. was due only to its incomplete implementation by Apple: i.e., only a software issue; until I read this, among others:
So, is it also a hardware issue (which would make nested VMs impossible on the M1)…? If that is the case, those who need nested virtualization would necessarily have to wait for M2 or M3 MacBook Pros, or similar…
Mx virtualization is early days, so limitations/futures are really foggy.
What's the use case for nested virtualization on M1's? You can't do it to run Intel guests if that's what the thought is.
For example, WSL 2 inside a Windows 11 ARM guest, on M1: that doesn’t seem to be possible, now. What isn’t so clear is if this is only a software issue, which could eventually be superseded by a more evolved Apple virtualization framework; or if it is also a limitation of the M1 at the hardware level, as some people say: who knows - difficult to say…
Well, we'd need windows support first 😉
Seriously, that's a really good question. Apple's sort of half-supporting/tolerating virtualization apps these days, but I suspect it was below the line on the silicon design team's list. Be interesting to find out.
It would appear ARM v8.4 supports nested virtualisation.
Isn't M1 based on ARM v8.5? So, it is likely an Apple hypervisor framework limitation rather than an ARM limitation (unless somehow Apple chose not to implement them in their own M series of CPUs).
Sadly, here the developers of Asahi Linux (who should know the M1 well) say that only the M2 probably will support nested virtualization:
In addition, Apple would have to support it in software, too…
It would be interesting if the virtualisation/nested virtualisation is already inside the silicon but just not enabled. I remember when VMware Workstation started using Intel VT-x, I had a Dell laptop and it simply required a BIOS update for the Intel VT-x to be enabled; so the Intel VT-x feature was already sitting inside the silicon.
Also wonder if Apple would make a distinction of virtualisation/nested virtualisation features (or any other features) between the normal M1 from M1 Pro, M1 Max (or for any other future M series CPUs). Surely, it can't be just core count that makes for difference in pricing/performance. I have no idea what the licensing/royalty fee agreement is like between ARM and Apple but it is entirely possible that adding in certain CPU feature/designs might require extra royalty payments. But Apple being Apple it is quite unlikely they will let end-users control the CPU features just like what PC world does in the UEFI/BIOS.
Certainly, it would be cool if features could simply be unlocked: but Apple should probably first show much more interest in bringing a complete virtualisation solution to the new Mx Macs (one would indeed expect full feature parity with Intel-on-Intel virtualisation, for ARM-on-ARM virtualisation, eventually)…
My guess is Apple wants to control all virtualisation through their Hypervisor Framework APIs; and that's what probably make it look like Apple is not fully embracing virtualisation. If they don't get this control right from the get-go, it will be difficult to stop somebody creating an iOS or iPadOS VM running on Apple Mx Macs.
One of the use cases would be running a macOS VM with Xcode is to develop for iOS/iPadOS and not using a simulator (like what is done now with Xcode on Intel Macs) but run these iOS/iPadOS as VMs instead (or nested virtualisation if the Xcode is running inside a macOS VM).
Anyway, looks like there are beta API and sample code for creating macOS VM running on Apple Silicon.
Tend to agree. With the deprecation and eventual removal of "legacy" kernel extensions, the only way that virtualization is going to work is via ULM's and macOS APIs such as the Hypervisor Framework. They have to get the APIs right and fully featured enough for the whole thing to work.