diff --git a/.github/workflows/docker-image.yaml b/.github/workflows/docker-image.yaml
index d30925002..fa0ae706c 100644
--- a/.github/workflows/docker-image.yaml
+++ b/.github/workflows/docker-image.yaml
@@ -1,4 +1,4 @@
-name: Cloud-Hypervisor's Docker image update
+name: Cloud Hypervisor's Docker image update
 
 on:
   push:
diff --git a/docs/custom-image.md b/docs/custom-image.md
index 47168f3e6..fc972376e 100644
--- a/docs/custom-image.md
+++ b/docs/custom-image.md
@@ -72,7 +72,7 @@ mount -t devpts devpts /dev/pts
 
 ### Install needed packages
 
-In the context Cloud-Hypervisor's integration tests, we need several utilities.
+In the context Cloud Hypervisor's integration tests, we need several utilities.
 Here is the way to install them for a Ubuntu image. This step is specific to
 Ubuntu distributions.
 
diff --git a/docs/intel_sgx.md b/docs/intel_sgx.md
index 58be64801..69a392508 100644
--- a/docs/intel_sgx.md
+++ b/docs/intel_sgx.md
@@ -1,7 +1,7 @@
 # Intel SGX
 
 Intel® Software Guard Extensions (Intel® SGX) is an Intel technology designed
-to increase the security of application code and data. Cloud-Hypervisor supports
+to increase the security of application code and data. Cloud Hypervisor supports
 SGX virtualization through KVM. Because SGX is built on hardware features that
 cannot be emulated in software, virtualizing SGX requires support in KVM and in
 the host kernel. The required Linux and KVM changes can be found in the
@@ -17,12 +17,12 @@ For more information about SGX, please refer to the [SGX Homepage](https://softw
 For more information about SGX SDK and how to test SGX, please refer to the
 following [instructions](https://github.com/intel/linux-sgx).
 
-## Cloud-Hypervisor support
+## Cloud Hypervisor support
 
 Assuming the host exposes `/dev/sgx_vepc`, we can pass SGX enclaves through
 the guest.
 
-In order to use SGX enclaves within a Cloud-Hypervisor VM, we must define one
+In order to use SGX enclaves within a Cloud Hypervisor VM, we must define one
 or several Enclave Page Cache (EPC) sections. Here is an example of a VM being
 created with 2 EPC sections, the first one being 64MiB with pre-allocated
 memory, the second one being 32MiB with no pre-allocated memory.
diff --git a/docs/memory.md b/docs/memory.md
index 8ea9554a5..2fdc84bdf 100644
--- a/docs/memory.md
+++ b/docs/memory.md
@@ -1,13 +1,13 @@
 # Memory
 
-Cloud-Hypervisor has many ways to expose memory to the guest VM. This document
-aims to explain what Cloud-Hypervisor is capable of and how it can be used to
+Cloud Hypervisor has many ways to expose memory to the guest VM. This document
+aims to explain what Cloud Hypervisor is capable of and how it can be used to
 meet the needs of very different use cases.
 
 ## Basic Parameters
 
 `MemoryConfig` or what is known as `--memory` from the CLI perspective is the
-easiest way to get started with Cloud-Hypervisor.
+easiest way to get started with Cloud Hypervisor.
 
 ```rust
 struct MemoryConfig {
diff --git a/docs/snapshot_restore.md b/docs/snapshot_restore.md
index df208ca55..63a0a181d 100644
--- a/docs/snapshot_restore.md
+++ b/docs/snapshot_restore.md
@@ -11,9 +11,9 @@ before the snapshot was performed.
 This feature is important for the project as it establishes the first step
 towards the support for live migration.
 
-## Snapshot a Cloud-Hypervisor VM
+## Snapshot a Cloud Hypervisor VM
 
-First thing, we must run a Cloud-Hypervisor VM:
+First thing, we must run a Cloud Hypervisor VM:
 
 ```bash
 ./cloud-hypervisor \
@@ -54,7 +54,7 @@ drwxr-xr-x 47 foo bar       4096 Jul 22 11:47 ../
 In this particular example, we can observe that 2 memory region files were
 created. That is explained by the size of the guest RAM, which is 4GiB in this
 case. Because it exceeds 3GiB (which is where we can find a ~1GiB memory hole),
-Cloud-Hypervisor needs 2 distinct memory regions to be created. Each memory
+Cloud Hypervisor needs 2 distinct memory regions to be created. Each memory
 region's content is stored through a dedicated file, which explains why we end
 up with 2 different files, the first one containing the guest RAM range 0-3GiB
 and the second one containing the guest RAM range 3-4GiB.
@@ -65,7 +65,7 @@ with the correct amount of CPUs, RAM, and other expected devices. The state
 bits are used to restore each component in the state it was left before the
 snapshot occurred.
 
-## Restore a Cloud-Hypervisor VM
+## Restore a Cloud Hypervisor VM
 
 Given that one has access to an existing snapshot in `/home/foo/snapshot`,
 it is possible to create a new VM based on this snapshot with the following 
diff --git a/release-notes.md b/release-notes.md
index 03006f4af..6967696ca 100644
--- a/release-notes.md
+++ b/release-notes.md
@@ -1244,7 +1244,7 @@ Highlights for `cloud-hypervisor` version 0.4.0 include:
 
 ### Dynamic virtual CPUs addition
 
-As a way to vertically scale Cloud-Hypervisor guests, we now support dynamically
+As a way to vertically scale Cloud Hypervisor guests, we now support dynamically
 adding virtual CPUs to the guests, a mechanism also known as CPU hot plug.
 Through hardware-reduced ACPI notifications, Cloud Hypervisor can now add CPUs
 to an already running guest and the high level operations for that process are