diff --git a/content/docs/concepts/virtualization.mdx b/content/docs/concepts/virtualization.mdx
index 2d15f04a..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,38 +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 is usually run in 2 ways:
-
-* As a virtual machine, using [**QEMU-KVM**](/docs/operations/plats/kvm/) or
-  [**Xen**](/docs/operations/plats/xen/). 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, allowing advanced functionalities.
-* As a [**linuxu**](/docs/operations/plats/linuxu/) build, in which it behaves
-  as a Linux user-space application. This severely limits its performance, as
-  everything Unikraft does must go through the Linux kernel, via system calls.
-  This mode should be used only for development and debugging.
+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
+hardware components that it needs (clocks, additional processors, etc).
+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
diff --git a/content/docs/contributing/unikraft.mdx b/content/docs/contributing/unikraft.mdx
index 2771b850..e784efd9 100644
--- a/content/docs/contributing/unikraft.mdx
+++ b/content/docs/contributing/unikraft.mdx
@@ -51,13 +51,13 @@ In order to simplify reading and searching the patch history, please use the fol
 
 Where `[selector]` can be one of the following:
 
-| Selector    | Description                                                                                                                                                           |
-|-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `arch`      | Patch for the architecture code in `arch/`,  `[component]` is the architecture (e.g, `x86`) applies also for corresponding headers in `include/uk/arch/`.             |
-| `plat`      | Patch for one of the platform libraries in `plat/`, `[component]` is the platform (e.g, `linuxu`).  This applies also for corresponding headers in `include/uk/plat/` |
-| `include`   | Changes to general Unikraft headers (e.g. `include/`, `include/uk`).                                                                                                   |
-| `lib`       | Patch for one of the Unikraft base libraries (not external) in `lib/`, `[component]` is the library name without lib prefix (e.g, `fdt`).                             |
-| `build`     | Changes to build tool or generic configurations, `[component]` is optional.                                                                                         |
+| Selector    | Description                                                                                                                                                                  |
+|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `arch`      | Patch for the architecture code in `arch/`,  `[component]` is the architecture (e.g, `x86_64` or `arm64`) applies also for corresponding headers in `include/uk/arch/`.      |
+| `plat`      | Patch for one of the platform libraries in `plat/`, `[component]` is the platform (e.g, `qemu`, `firecracker` or `xen`).  This applies also for corresponding headers in `include/uk/plat/` |
+| `include`   | Changes to general Unikraft headers (e.g. `include/`, `include/uk`).                                                                                                         |
+| `lib`       | Patch for one of the Unikraft base libraries (not external) in `lib/`, `[component]` is the library name without lib prefix (e.g, `fdt`).                                    |
+| `build`     | Changes to build tool or generic configurations, `[component]` is optional.                                                                                                  |
 
 > Commit messages, along with all source files follow a 80-character rule.
 
diff --git a/content/docs/internals/booting.mdx b/content/docs/internals/booting.mdx
index e562b977..f771f303 100644
--- a/content/docs/internals/booting.mdx
+++ b/content/docs/internals/booting.mdx
@@ -1,12 +1,12 @@
 ---
 title: Booting
 description: |
-  Unikraft has an prograrmmable boot sequence which provides the ability to inject functionality at different moments of system initialization.  Learn how to how and where to introduce custom functionality.
+  Unikraft has a prograrmmable boot sequence which provides the ability to inject functionality at different moments of system initialization.  Learn how to and where to introduce custom functionality.
 ---
 
 ## Unikraft Boot Sequence
 
-The Unikraft boot sequence is dependent on the selected platform (linuxu, kvm, xen), but is very similar to how any other operating system would behave.
+The Unikraft boot sequence is dependent on the selected platform (`qemu`, `firecracker` or `xen`), but is very similar to how any other operating system would behave.
 
 In the case of the `KVM` platform, the booting process involves more steps.
 First, the image is loaded from the disk into memory and the program sections are defined (see `plat/kvm/x86/link64.lds.S`, as example for the x86 architecture).
diff --git a/content/docs/internals/debugging.mdx b/content/docs/internals/debugging.mdx
index 34a7ef1a..49b7d2e3 100644
--- a/content/docs/internals/debugging.mdx
+++ b/content/docs/internals/debugging.mdx
@@ -40,14 +40,6 @@ We recommend 3, the highest level.
 
 Once set, save the configuration and build your images.
 
-#### Linuxu
-
-For the Linux user space target (`linuxu`) simply point GDB to the resulting debug image, for example:
-
-```console
-$ gdb build/app-helloworld_linuxu-x86_64.dbg
-```
-
 #### KVM
 
 For KVM, you need to start the guest with the kernel image that does not include debugging information.