Talk:Virtualization

Generally speaking the relative performance overhead of various virtualization techniques are affected by too many factors to sufficiently say that a user can expected the shown performance impact as that ultimately only comes down to that specific system and scenario.

Just to name a few of the factors involved:

• Underlying physical hardware of the system
• Thermals/cooling characteristics of the system
• BIOS/UEFI settings, CPU core/memory frequency settings, hardware-assisted virtualization being enabled, speculative executions (whether they are allowed to engage or not), etc
• Host operating system (if it involves an underlying Type 1 hypervisor or not)
• Virtualization solution (if it involves an underlying Type 1 hypervisor, or if its run as a Type 2 hypervisor)
  • This one in particular is complicated as Hyper-V is always a Hype 1 hypervisor, even when installed on a consumer Windows install, and with consumer versions of Windows featuring virtualization based security that relies on Hyper-V it is quite often that a user might have Hyper-V enabled without realizing it and without the feature selected
  • This also means that VMware Workstation 15.5+ as well as VirtualBox 6.0+ (and other newer alternatives) on Windows 10 and 11 runs through the Windows Hypervisor Platform APIs when Hyper-V is being used on the system, which also may have an impact on performance
• Virtualized hardware/software/application, and its various characteristics in relation to the rest of the system as well as actual physical hardware of the system
• and so on...

As a result it is all but impossible to properly account for all factors involved that may affect performance, and summarizing it down to a single relative performance table that does not account for most of these factors ends up being wildely misleading for the average reader with barely any insight into the topic.

Ergo, we should strive to keep away from performance figures and claims as much as possible other than in a loose sense (e.g. hardware-assisted virtualization allows for improved performance compared to without them).

So.. Putting aside fancy solutions like Cooperative VMs, paravirtualization and containers there are several levels to the thing.

If we are just caring for x86, once upon a time there were just full architecture emulator/simulators like Bochs, I guess. Not very differently from any modern console emulator you could say.

Then VMware came in 1999 with binary translation and performance became a thing. Not that the technique itself is fast (QEMU also has a nice JIT recompiler by default, but that's far from native speed), but because it allowed to overcome the x86 insidiousnesses and use direct execution in most other places people actually cared for (i.e. normal applications).

As a fun fact this could not have been used on Intel CPUs to virtualize 64 bit efficiently. And since VirtualBox 6.1 and Workstation 14 it is not even supported anymore.

Thankfully between 2005 and 2006 Intel and AMD made classical trap-and-emulate virtualization possible, and that's what VT-X and AMD-V are all about eventually. It is more about lessening the burden to have a smart hypervisor (and perhaps some edge case) than performance though. And for historical reason, I'm not sure if solutions other than VMware's ever supported "64 bit at all" without it. It is also needed for 64/32 and 32/64 bit mixed host and guests (KVM doesn't support the latter for reasons)

Note: when Hyper-V is enabled, it pretends "Hardware Virtual Machine"s not to be supported.

And then it came SLAT. Which simplified as much as possible memory management (not to be confused with the previous handling of just the instruction set), leading also to performance increases, and it is becoming a hard requirement in a lot of modern products, from Hyper-V, to HAXM, and Workstation ≥14. It is known as RVI on the AMD front and EPT on the Intel one. Even though in the later case, depending on the mood of a hypervisor (or maybe the key difference is being Type-2 rather than Type-1?), they may actually be required to support "Unrestricted guests" too. Aka leaving Bloomfield in the dirt.

But when everything seemed all finally nice smooth and dandy, from 2018 onward another important factor distinguishing the various programs is how good they managed to wire and/or workaround the various speculative execution vulnerabilities and mitigations.

---

Tangential to all of this, last but not least, VT-d/AMD-Vi/IOMMU is the magic allowing passing through of physical hardware devices to guests. It requires support in the motherboard chipset and bios, in addition to the usual one by the CPU.

EDIT: it actually happens to be a requirement only for devices using DMA.. such as about everything and the kitchen sink in 2020. But if you have a gpu from the 90s (and a PCI slot? people really have mixed opinions on whether bus mastering is an integral part of PCIe or not) you should be done!

Otherwise paravirtualization is the only hope left.