KVM turning Linux kernel into a Type 1 Hypervisor

Question

I’ve been reading about KVM, and I came across the statement:

“When the KVM module is loaded, the Linux kernel itself becomes a Type 1 hypervisor.”

I want to clarify if my understanding is correct using a concrete example.

Suppose I install Ubuntu 24.04 "Noble Numbat" on bare metal and enable KVM. Then, I create two VMs:

• Ubuntu 22.04 "Jammy Jellyfish"
• Ubuntu 20.04 "Focal Fossa"

My mental model looks like this:

┌─────────────────────────┬─────────────────────────┬─────────────────────────┐
│ Applications            │ Applications            │ Applications            │
│ (Noble)                 │ (Jammy)                 │ (Focal)                 │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│ System Layer            │ System Layer            │ System Layer            │
│ (Noble)                 │ (Jammy)                 │ (Focal)                 │
│ [Libraries, Runtime     │ [Libraries, Runtime     │ [Libraries, Runtime     │
│  Utilities]             │  Utilities]             │  Utilities]             │
│                         ├─────────────────────────┬─────────────────────────┤
│                         │ Linux Kernel            │ Linux Kernel            │
│                         │ (Jammy)                 │ (Focal)                 │
├─────────────────────────┼─────────────────────────┴─────────────────────────┤
│                         │              Type 1 Hypervisor                    │
│ Linux Kernel (Noble)    │          [Linux Kernel (Noble) + KVM]             │
├─────────────────────────┴───────────────────────────────────────────────────┤
│                Hardware (CPU, RAM, Disk, NIC, etc.)                         │
└─────────────────────────────────────────────────────────────────────────────┘

Is this diagram correct?

Answer 1

I'm going to go ahead and contradict. The 1973 idea¹ of what types of hypervisors there are is just stupidly far away from post-2000's reality.

The Linux kernel running on say an x86 or arm64 processor with KVM modules is not a Type I hypervisor. It's also not a Type II hypervisor.

The idea of Type I is that "the hypervisor runs, without an OS, on bare metal". Now, KVM guest do not at all run on bare metal. The virtual machine monitor (Qemu, in most cases) uses the KVM kernel module, of course, to execute the privileged operations needed to initialize the nested paging needed, and for some types of monitoring. But the VMM runs as process on a normal OS! So, definitely not Type I from 1973.

Even if there was no userland process to speak to KVM, and everything was handled in-kernel, the rest of the kernel is still a fully-fledged OS, and KVM uses the kernel as operating system – even if KVM is part of the kernel itself. It's definitely not bare metal, if someone else cares for your memory view of the system, provides you with filesystem and character device services, even memory-mapped file IO, networking and so on!

Is, say, Qemu + KVM a Type II hypervisor? Pretty much, but not quite: The actual VMM (virtual machine monitor) is Qemu – a classical userland process running on an OS; according to the Type I/II nomenclature, that's a Type II VMM.

KVM is just a device driver, if you will. But that's not a Type II hypervisor, either, because it's a driver for a CPU feature, if you will. So, Qemu (or firecracker, or whatever VMM you use with KVM) + KVM is neither Type I nor Type II. To little surprise, computers have changed since the mainframe times of 1973, when these terms were invented.

Things get a lot more complicated when you actually look on what things actually make up modern VMs. If you have a modern workstation or server CPU, it has an IO controller that has an IO-MMU. Something that would totally be part of a Type I hypervisor is a hardware feature that can be used by software however that software sees fit. It can be used in a Type I-style manner (e.g. by Xen mapping some device to a DomU), or it can totally be used in a Type-II-style manner (by Qemu requesting mappings for a IOMMU group), or it can still be used as if it was a hypervisor, virtualizing memory view and device functionality, completely by userland software running on an OS without any VMs involved (as for example common in DPDK).

So, if you're having the advantage of having 50 years between you and the beginnings of virtualization – do try to understand the old terms if it's interesting to you, but don't try to squeeze modern software into terms coined by people for whom the microcontroller displaying the time on your dumb microwave oven would have been a high-performance mainframe-class processor.

---

¹ Yes, these terms are more than 50 years old. They described machines thinkable at the time. Now, does your PC have more than 1 MB of RAM? Then it was pretty much unimagined back then. Anyways, the definition of Type I/II is from page 22 of Robert P. Goldberg's "Architectural Principles for Virtual Computer Systems," available online, from 1973 (page 22 of the document is on page 42 of the pdf).

Answer 2

More or less. The second-to-last row should be a unique unsplit cell, in my opinion, as the Linux kernel which runs the host OS (Ubuntu Noble) is the same which runs the two VMs (Ubuntu Jammy and Focal).