I have ever only heard KVM in the context of a Keyboard Video Monitor-type device but somehow I can't fully fit that into the concept of a virtual machine. Does it mean something different here?
Funny enough, a KVM might be needed for KVM if you give the VM control of a USB hub and a discrete GPU using IOMMU and you only have one monitor and set of peripherals, but two hubs and an integrated GPU.
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.
Is there a connection to User Mode Linux (UML) from around the same
time? Or are these completely unrelated projects? I get that running
a kernel in the user space provided by another kernel is not really
the same as a proper hypervisor, but have never really dug deep into
why and what the various tradeoffs are.
There is no real connection to UML here. Hardware virtualization (Intel VT, AMD-V) are much faster in practice and also don't require the guest operating system to be heavily modified. So besides as curiosity or test vehicle, approaches like UML are pretty dead.
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.
Yes - plus the original win of UML was also being able to run virtual instances on a kernel without proper virtualization capabilities.
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.
The “original” UML is/was, I believe, NetBSD running as a “rump kernel” and something that virtualization of the actual kernel does not, directly and on its own, fill the shoes of.
