[PATCH] 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.
I checked using dictionaries to be sure.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@xxxxxxxxx>
---
 docs/admin-guide/microcode-loading.rst    | 4 ++--
 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 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/docs/admin-guide/microcode-loading.rst 
b/docs/admin-guide/microcode-loading.rst
index a07e25802f..f9b2b73d17 100644
--- a/docs/admin-guide/microcode-loading.rst
+++ b/docs/admin-guide/microcode-loading.rst
@@ -20,7 +20,7 @@ distro guidance for microcode loading.
 Microcode can make almost arbitrary changes to the processor, including to
 software visible features.  This includes removing features (e.g. the Haswell
 TSX errata which necessitated disabling the feature entirely), or the addition
-of brand new features (e.g. the Spectre v2 controls to work around speculative
+of brand-new features (e.g. the Spectre v2 controls to work around speculative
 execution vulnerabilities).
 
 
@@ -40,7 +40,7 @@ Xen will report during boot if it performed a microcode 
update::
   (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02
 
 The exact details printed are system and microcode specific.  After boot, the
-current microcode version can obtained from with dom0::
+current microcode version can be obtained from with dom0::
 
   [root@host ~]# head /proc/cpuinfo
   processor    : 0
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..43010227e5 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