Hypervisors - Part 1
Introduction⌗
Hi all, this is my ever blog post. I’m a bit nervous but also really excited to start sharing my ideas and quest of learning with whoever reads this. Ready to start? Me too. Let’s go!
So for my first post, I’m going to talk about a subject that has recently fascinated me: Hypervisors. I don’t know about you, but hypervisors have always confused the hell out of me. With a definitions such as “type of computer software, firmware or hardware that creates and runs virtual machines” [1] or a “supervisor of the supervisors,” it’s a bit hard to initially discern what a Hypervisor does and how it works. Let’s change that!
Overview⌗
A hypervisor is nothing more than a program that allows you to spin up another operating system in a virtualized environment. Given this definition, we can note that there exists two types of such virtualization:
- Type 1 virtualization
- Type 2 virtualization
Type 1 virtualization⌗
Type 1 virtualization is a type of hypervisor that runs between the bare metal hardware of your system and your virtual machines. It’s essentially the broker through which all hardware <-> VM interactions pass through. In this type of virtualization, there is no main operating system through which we spin VMs up. Rather, all operating systems running on the hardware are virtualized and are therefore equals for all intensive purposes.
Type 2 virtualization⌗
Type 2 virtualization is another type of hypervisor that runs on a “main” operating system and allows us to spin up VMs sort of “within” that operating system. In this system, interactions take on the form hardware <-> main OS <-> VMs, where our VMs DO NOT communicate directly with the hardware of our system. Instead, it relies on the operating system to provide us indirect access to the underlying hardware.
Now you may be wondering, mister blog person, is there really no way to get a VM running via a type 2 hypervisor to communicate directly with the hardware? Ahh, that’s a great question. There actually is through a mechanism called nested virtualization.
Nested virtualization is a (sometimes optional) CPU extension that allows
This is actually the reason why a VM running on an Apple M1 SoC can’t directly communicate with the hardware, as Apple did not implement nested virtualization on its CPUs until the M2 series. In order for a VM to directly communicate with the hardware on M1, you need a custom bootloader and hypervisor such as m1n1 which will effectively run a hypervisor in exception level EL2 and MacOS at EL3, thus providing type 1 virtualization.