https://en.m.wikipedia.org/wiki/Kernel-based_Virtual_Machine
So, slow as it may be, the win for UML (which seems to still have a heartbeat) is that it can run on uP without any specific virtualisation capabilities, right? If I could run Linux on a Z80/6502 then in theory I could run a virtualised Linux on a Z80/6502.
In the early 2000s people used to use UMLs as a hosting platform - they didn't have the same security isolation as a proper VM (or even, necessarily, of a container) though.
There are two large hypervisors in the Linux world.
Xen, which extends the kernel to support virtual CPUs with time slices.
KVM, which assigns each virtual core a process that uses the Linux scheduler.
When a hardware vm vcpu core is preempted there is vmexit call that has to reset registers etc... and it is expensive.
Xen is what legacy AWS instances ran on and has advantages for being fair to guests is an easier task.
KVM has the advantage of gaining the benefits of the Linux scheduler which is red black tree based and well optimized.
When a new CPU comes out for example, KVM gains support from the upstream while Xen has to support it themselves.
Once technology like cgroups improved the benefits of letting your thread complete and not be preempted due to the time slice expiring avoided the cost of vmexit.
In theory, leveraging the inherently optimized core Linux features is what will also benefit virtualbox.
Most people who use KVM are using an abstraction layer like libvirt that hides how it is implemented.
In fact if you look at the processes you will see qemu even if KVM is how it is implemented.