I'm somewhat confused by this rhetorical question since the microcode of processor is vastly different than the userspace & kernel of Mac OS. Running an OS bare metal versus in a VM on top of Mac OS are different across a wide array of things. At a minimum performance is lower and less predictable on the VM; you now have two different OS's updates to worry about breakage with on top of their mutual interface (ask anyone who's done serious Linux dev work on a Mac); you have two different sets of security policies to worry about; the low level tools to debug performance in a VM don't have the level of access they do on bare metal; and if you're working with hardware for linux servers & devices in a VM you are going to have to go bare metall sooner or later.
The abstractions are leaky, the VM is not a pristine environment floating on top of some vaguely well-defined architecture. The software in one has two extra layers (VM software & OS) between it and the actual platform and all this is before you start hitting weird corner cases with cpu architecture differences in the layers.
Hmm, really? Since Windows 10 your desktop runs in a guest domain, while the kernel running the drivers is isolated.
Since about 5 years Apple provides this kit: https://developer.apple.com/documentation/hypervisor Yeah, you got to use the hardware drivers from Apple unless it also supports PCI pass through, not sure but with the current user base I guess nobody would do that anyway.
I expect Apple to eventually run their ring-1 off the T chip, with everything else from a VM abstraction. It’s just the natural evolution of the UEFI approach, and Apple being themselves they’re doing it “their way” without waiting for the crossfire infested industry committees to play along.
