From 6b90245e52e55e649bd1f447f06cbfc4e406acdd Mon Sep 17 00:00:00 2001 From: Todor Todorov Date: Sun, 14 Jul 2024 21:40:02 +0300 Subject: [PATCH 1/3] docs: Remove any reference to plat linuxu Platform linuxu has been removed in Unikraft 0.17. Signed-off-by: Todor Todorov --- content/docs/concepts/virtualization.mdx | 17 ++++++----------- content/docs/contributing/unikraft.mdx | 14 +++++++------- content/docs/internals/booting.mdx | 2 +- content/docs/internals/debugging.mdx | 8 -------- 4 files changed, 14 insertions(+), 27 deletions(-) diff --git a/content/docs/concepts/virtualization.mdx b/content/docs/concepts/virtualization.mdx index 2d15f04a..009bf738 100644 --- a/content/docs/concepts/virtualization.mdx +++ b/content/docs/concepts/virtualization.mdx @@ -61,17 +61,12 @@ 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 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..970345f1 100644 --- a/content/docs/internals/booting.mdx +++ b/content/docs/internals/booting.mdx @@ -6,7 +6,7 @@ description: | ## 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. From 415f978ffeea2e1a3afd1f6efda31387e5a4119f Mon Sep 17 00:00:00 2001 From: Todor Todorov Date: Sun, 21 Jul 2024 17:29:17 +0300 Subject: [PATCH 2/3] docs/internals: Fix typos Signed-off-by: Todor Todorov --- content/docs/internals/booting.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/internals/booting.mdx b/content/docs/internals/booting.mdx index 970345f1..f771f303 100644 --- a/content/docs/internals/booting.mdx +++ b/content/docs/internals/booting.mdx @@ -1,7 +1,7 @@ --- 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 From b0a0fdeeada4b1025ab658f68e678825b0e969be Mon Sep 17 00:00:00 2001 From: Todor Todorov Date: Fri, 9 Aug 2024 11:41:50 +0000 Subject: [PATCH 3/3] docs/concepts: Fix markdown linting --- content/docs/concepts/virtualization.mdx | 67 +++++++++++++----------- 1 file changed, 35 insertions(+), 32 deletions(-) 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.