Manual pages: Fix a few typos

While skimming through the manual pages, I spotted a few typos.

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff --git a/docs/man/xen-vtpmmgr.7.pod b/docs/man/xen-vtpmmgr.7.pod
index 3286954568827fed00f04384397c71583369b67a..95854adb0885d274643b8835b7b0e13871a3f2bc 100644 (file)
--- a/docs/man/xen-vtpmmgr.7.pod
+++ b/docs/man/xen-vtpmmgr.7.pod
@@ -297,7 +297,7 @@ extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
     |   Primary Seed   |
     +------------------+
 
-Now the secrets for the vTPMs are only being bound to the presence of thephysical
+Now the secrets for the vTPMs are only being bound to the presence of the physical
 TPM 2.0. Since using PCRs to seal the data can be an important security feature
 that users of the vtpmmgr rely on. I will replace TPM2_Bind/TPM2_Unbind with
 TPM2_Seal/TPM2_Unseal to provide as much security as it did for TPM 1.2 in later

diff --git a/docs/man/xl-numa-placement.7.pod b/docs/man/xl-numa-placement.7.pod
index 802f33060bfcf9512bd4880978abcb44674af3db..4d83f26d412ee176500614518c007a7cf68a43c5 100644 (file)
--- a/docs/man/xl-numa-placement.7.pod
+++ b/docs/man/xl-numa-placement.7.pod
@@ -45,7 +45,7 @@ user, via the proper libxl calls or xl config item, it will be computed
 basing on the vCPUs' scheduling affinity.
 
 Notice that, even if the node affinity of a domain may change on-line,
-it is very important to "place" the domain correctly when it is fist
+it is very important to "place" the domain correctly when it is first
 created, as the most of its memory is allocated at that time and can
 not (for now) be moved easily.
 
@@ -94,7 +94,7 @@ this reason, NUMA aware scheduling has the potential of bringing
 substantial performances benefits, although this will depend on the
 workload.
 
-Notice that, for each vCPU, the following three scenarios are possbile:
+Notice that, for each vCPU, the following three scenarios are possible:
 
 =over
 
@@ -102,7 +102,7 @@ Notice that, for each vCPU, the following three scenarios are possbile:
 
 a vCPU I<is pinned> to some pCPUs and I<does not have> any soft affinity
 In this case, the vCPU is always scheduled on one of the pCPUs to which
-it is pinned, without any specific peference among them.
+it is pinned, without any specific preference among them.
 
 
 =item *