[PATCH v2] docs: Improve spelling of few cases in the documentation

[Bernhard Kaindl <bernhard.kaindl@xxxxxxxxx>]

Skimming the docs, I came across a few places for spelling improvements.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@xxxxxxxxx>
---
Changes in v2:
- Apply review of v1: Leave "brand new" and omit changes that Andy will do.
- "binary-patch" -> "binary patch" ("binarily patch" is okay but uncommon)
---
 docs/designs/non-cooperative-migration.md | 4 ++--
 docs/designs/qemu-deprivilege.md          | 2 +-
 docs/guest-guide/x86/hypercall-abi.rst    | 2 +-
 docs/man/xl.conf.5.pod.in                 | 2 +-
 docs/misc/livepatch.pandoc                | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/designs/non-cooperative-migration.md 
b/docs/designs/non-cooperative-migration.md
index 4b876d809f..54496892ed 100644
--- a/docs/designs/non-cooperative-migration.md
+++ b/docs/designs/non-cooperative-migration.md
@@ -112,7 +112,7 @@ because the guest can sample its own domid from the 
frontend area and use
 it in hypercalls (e.g. HVMOP_set_param) rather than DOMID_SELF, the guest
 domid must also be preserved to maintain the ABI.
 
-Furthermore, it will necessary to modify backend drivers to re-establish
+Furthermore, it will be necessary to modify backend drivers to re-establish
 communication with frontend drivers without perturbing the content of the
 backend area or requiring any changes to the values of the xenstore state
 nodes.
@@ -259,7 +259,7 @@ Essentially this should skip the check to see if PV drivers 
and migrate as
 if there are none present, but also enabling the extra save records. Note
 that at least some of the extra records should only form part of a
 non-cooperative migration stream. For example, migrating event channel
-state would be counter productive in a normal migration as this will
+state would be counter-productive in a normal migration as this will
 essentially leak event channel objects at the receiving end. Others, such
 as grant table state, could potentially harmlessly form part of a normal
 migration stream.
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index 81a5f5c05d..f12b1a3ae3 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/docs/designs/qemu-deprivilege.md
@@ -3,7 +3,7 @@
 The goal of deprilvileging qemu is this: Even if there is a bug (for
 example in qemu) which permits a domain to gain control of the device
 model, the compromised device model process is prevented from
-violating the system's overall security properties.  Ie, a guest
+violating the system's overall security properties.  I.e., a guest
 cannot "escape" from the virtualisation by using a qemu bug.
 
 This document lists the various technical measures which we either
diff --git a/docs/guest-guide/x86/hypercall-abi.rst 
b/docs/guest-guide/x86/hypercall-abi.rst
index 745fbbb64a..e52ed453bc 100644
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -109,7 +109,7 @@ abstracting away the details of how it is currently running.
 Creating Hypercall Pages
 ------------------------
 
-Guests which are started using the PV boot protocol may set set
+Guests which are started using the PV boot protocol may set
 ``XEN_ELFNOTE_HYPERCALL_PAGE`` to have the nominated page written as a
 hypercall page during construction.  This mechanism is common for PV guests,
 and allows hypercalls to be issued with no additional setup.
diff --git a/docs/man/xl.conf.5.pod.in b/docs/man/xl.conf.5.pod.in
index 44738b80bf..0cfec8587c 100644
--- a/docs/man/xl.conf.5.pod.in
+++ b/docs/man/xl.conf.5.pod.in
@@ -4,7 +4,7 @@
 
 =head1 DESCRIPTION
 
-The F<xl.conf> file allows configuration of hostwide C<xl> toolstack
+The F<xl.conf> file allows configuration of host-wide C<xl> toolstack
 options.
 
 For details of per-domain configuration options please see
diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index a94fb57eb5..4a0b4fd6d8 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -2,7 +2,7 @@
 
 ## Rationale
 
-A mechanism is required to binarily patch the running hypervisor with new
+A mechanism is required to binary patch the running hypervisor with new
 opcodes that have come about due to primarily security updates.
 
 This document describes the design of the API that would allow us to
-- 
2.43.0