Jörn Engel (joern.delete@this.purestorage.com) on January 13, 2021 8:49 am wrote:
> Maynard Handley (name99.delete@this.name99.org) on January 9, 2021 3:12 pm wrote:
> >
> > I ask this seriously: what does achieving raw metal linux achieve over VM linux?
>
> Maynard has demonstrated multiple times that he doesn't want to learn,
> but to argue. So this answer is explicitly for everyone else. ;)
>
> It is almost always about control.
> - I regularly see seconds of latency for high-priority realtime threads in VMs. I used to
> see similar problems on bare metal - until I fixed the bugs. Fixing hypervisor bugs in a
> Linux hypervisor is already too painful to consider, with OSX it is plain impossible.
> - There is no NMI timer interrupt, but you can simulate one by using performance counters. But inside
> a VM those counters don't work, so your interrupt only fires if you force the VM to burn CPU.
> - Every hypervisor intercepts some keys. I've had to crawl through menus with a mouse to piece
> together sysrq-something or ctrl-alt-del. Bare metal simply doesn't annoy you in such ways.
> - If you want to use the entire system, particularly all of RAM, the hypervisor will
> get in the way. You can pin two threads to two different CPUs inside the VM, but the
> hypervisor is still allowed to schedule those threads on the same physical CPU. Swap
> will happen in ways you cannot control. The entire VM may get killed without warning.

And another problem with Virtual Managers (but this one not only on Macs):
You might want to check your whole DRAM for failing bits, for instance using memtest under BIOS, and having a virtual (i386 real-mode) machine created by the EFI BIOS (with maximum 4 Gbytes of DRAM) will lead to a "memory error" or crash when attempting to check the DRAM at address 0x1_0000_0000...
I suppose someone will say that Macs have a perfect DRAM and never develop any randomly failing bit.