diff --git a/content/docs/concepts/virtualization.mdx b/content/docs/concepts/virtualization.mdx
index 009bf738..b594fec1 100644
--- a/content/docs/concepts/virtualization.mdx
+++ b/content/docs/concepts/virtualization.mdx
@@ -8,38 +8,41 @@ description: |
 
 Virtualization can be done using a hypervisor, which is a low-level software
 that virtualizes the underlying hardware and manages access to the real
-hardware, either directly or through the host Operating System. There are 2 main
-virtualized environments: virtual machines and containers, each with pros and
-cons regarding complexity, size, performance and security. Unikernels come
-somewhere between those 2.
+hardware, either directly or through the host Operating System.
+There are 2 main virtualized environments: virtual machines and containers,
+each with pros and cons regarding complexity, size, performance and security.
+Unikernels come somewhere between those 2.
 
 ## Virtual Machines
 
 A virtual machine represents an abstraction of the hardware, over which an
 operating system can run, thinking that it is alone on the system and that it
-controls the hardware below it. Virtual machines rely on hypervisors to run
-properly.
+controls the hardware below it.
+Virtual machines rely on hypervisors to run properly.
 
 A hypervisor incorporates hardware-enabled multiplexing and segmentation of
 compute resources in order to better utilize, better secure and better
-facilitate the instantenous runtime of user-defined programs. By the
-means of a virtual machine, an operating system is unaware of the multiplexing
-which happens to facilitate its existence. The hypervisor emulates devices on
-behalf of the guest OS, including providing access to virtual CPUs, virtual
-Interrupt Controllers and virtual NICs, which are segmented from the underlying
-hardware.
+facilitate the instantenous runtime of user-defined programs.
+By the means of a virtual machine, an operating system is unaware of the
+multiplexing which happens to facilitate its existence.
+The hypervisor emulates devices on behalf of the guest OS, including
+providing access to virtual CPUs, virtual Interrupt Controllers and virtual
+NICs, which are segmented from the underlying hardware.
 
 The hypervisors can be classified in 2 categories: Type 1 and Type 2:
 
 * The **Type 1 hypervisor**, also known as **bare-metal hypervisor**, has direct
   access to the hardware and controls all the operating systems that are running
-  on the system. The guest OSes have access to the physical hardware, and the
-  hypervisor arbiters this accesses. KVM is an example of Type 1 hypervisor.
+  on the system.
+  The guest OSes have access to the physical hardware, and the hypervisor
+  arbiters this accesses.
+  KVM is an example of Type 1 hypervisor.
 
-* The **Type 2 hypervisor**, also known as **hosted hypervisor**, has to go 
-  through the host operating system to reach the hardware. Access to the 
-  hardware is emulated, using software components that behave in the same way 
-  as the hardware ones. An example of Type 2 hypervisor is VirtualBox.
+* The **Type 2 hypervisor**, also known as **hosted hypervisor**, has to go
+  through the host operating system to reach the hardware.
+  Access to the hardware is emulated, using software components that behave
+  in the same way as the hardware ones.
+  An example of Type 2 hypervisor is VirtualBox.
 
 <Image
   border
@@ -51,33 +54,33 @@ The hypervisors can be classified in 2 categories: Type 1 and Type 2:
 
 In Figure 1 a comparison between different virtualization systems is illustrated
 and demonstrates how the degree of separation between a "guest application" and
-the hardware and “host” becomes further removed. The defined job of the host OS
-and kernel or hypervisor became that of 1). to juggle the runtime of multiple
-applications and environments; 2). to present a subset or non-contiguous
-representation of hardware resources virtually and translate operations, and
-provide emulation and compatibility between guest and host; and, 3). to
-ultimately guard access to them to prevent corruption or malicious attacks.
-
+the hardware and “host” becomes further removed.
+The defined job of the host OS and kernel or hypervisor became that of
+1) to juggle the runtime of multiple applications and environments;
+2) to present a subset or non-contiguous representation of hardware resources
+virtually and translate operations, and provide emulation and compatibility
+between guest and host; and,
+3) to ultimately guard access to them to prevent corruption or malicious attacks.
 
 ## Supported platforms
 
-Unikraft can be run as a virtual machine, using **KVM** (with QEMU 
+Unikraft can be run as a virtual machine, using **KVM** (with QEMU
 or Firecracker as VMMs) or **Xen**.
-It acts as an operating system, having the responsibility to configure the 
+It acts as an operating system, having the responsibility to configure the
 hardware components that it needs (clocks, additional processors, etc).
-This mode gives Unikraft direct and total control over hardware components, 
+This mode gives Unikraft direct and total control over hardware components,
 allowing advanced functionalities.
 
-When Unikraft is running using **QEMU-KVM**, it can either be run on an emulated
-system or a (para)virtualized one. Technically, **KVM** means virtualization
-support is enabled. If using **QEMU** in emulated mode, **KVM** is not used.
+When Unikraft is running using **QEMU-KVM**,
+it can either be run on an emulated system or a (para)virtualized one.
+Technically, **KVM** means virtualization support is enabled.
+If using **QEMU** in emulated mode, **KVM** is not used.
 
 Emulation is slower, but it allows using CPU architectures different from the
 local one (you can run ARM code on a x86 machine). Using (para)virtualisation,
 aka hardware acceleration, greater speed is achieved and more hardware
 components are visible to Unikraft.
 
-
 ## Future virtualization support
 
 Unikraft is planned to be able to run on **Hyper-V** and **VMWare**, in the near