docs: Fix some typos in the design docs

Skimming through the design docs, I saw some typos that needed fixing.

Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

docs/designs/argo.pandoc

@@ -58,7 +58,7 @@ concurrency.
 
 Avoidance of deadlock is essential and since state must frequently be updated
 that pertains to more than one domain, a locking protocol defines which locks
-are needed and the order of their acquistion.
+are needed and the order of their acquisition.
 
 ## Structure
 
@@ -127,7 +127,7 @@ by the domain.
 
 ## Hierarchical Locking Model and Protocol
 
-The locking discipline within the Argo code is heirarchical and utilizes
+The locking discipline within the Argo code is hierarchical and utilizes
 reader/writer locks to enable increased concurrency when operations do not
 conflict. None of the Argo locks are reentrant.
 
@@ -283,7 +283,7 @@ state for a domain's own registered ring.
 
 ## Reasoning Model
 
-A common model for reasoning about concurrent code focusses on accesses to
+A common model for reasoning about concurrent code focuses on accesses to
 individual variables: if code touches this variable, see that it first acquires
 the corresponding lock and then drops it afterwards. A challenge with this
 model is in ensuring that the sequence of locks acquired within nested

docs/designs/nested-svm-cpu-features.md

@@ -22,7 +22,7 @@ leaf 8000000A:edx
   from the L1 hypervisor's perspective to be as close as possible to
   the original hardware.  In particular, the behavior of the hardware
   on error paths 1) is not easy to understand or test, 2) can be the
-  source of surprising vulnerabiliies.  (See XSA-7 for an example of a
+  source of surprising vulnerabilities.  (See XSA-7 for an example of a
   case where subtle error-handling differences can open up a privilege
   escalation.)  We should avoid emulating any bit of the hardware with
   complex error paths if we can at all help it.
@@ -59,11 +59,11 @@ leaf 8000000A:edx
 
 - 2 `SVML` *SVM Lock*: Not required for L0, not provided to L1
 
-  Seems to be aboult enabling an operating system to prevent "blue
+  Seems to be about enabling an operating system to prevent "blue
   pill" attacks against itself.
 
   Xen doesn't use it, nor provide it; so it would need to be
-  implementend.  The best way to protect a guest OS is to leave nested
+  implemented.  The best way to protect a guest OS is to leave nested
   virt disabled in the tools.
 
 - 3 `NRIPS` NRIP Save: Require for both L0 and L1
@@ -78,8 +78,8 @@ leaf 8000000A:edx
   The main putative use for this would be trying to maintain an
   invariant TSC across cores with different clock speeds, or after a
   migrate.  Unlike others, this doesn't have an error path to worry
-  about compatibility-wise; and according to tests done when nestedSVM
-  was first implemented, it's actually faster to emliate TscRateMSR in
+  about compatibility-wise; and according to tests done when nested SVM
+  was first implemented, it's actually faster to emulate TscRateMSR in
   the L0 hypervisor than for L1 to attempt to emulate it itself.
 
   However, using this properly in L0 will take some implementation
@@ -89,7 +89,7 @@ leaf 8000000A:edx
  - 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
 
   This is a pure optimization, both on the side of the L0 and L1.  The
-  implementaiton for L1 is entirely Xen-side, so can be provided even
+  implementation for L1 is entirely Xen-side, so can be provided even
   on hardware that doesn't provide it.  And it's purely an
   optimization, so could be "implemented" by ignoring the bits
   entirely.
@@ -102,7 +102,7 @@ leaf 8000000A:edx
 - 6 `FlushByAsid`: Require for L0, provide to L1
 
   This is cheap and easy to use for L0 and to provide to the L1;
-  there's no reson not to just pass it through.
+  there's no reason not to just pass it through.
 
 - 7 `DecodeAssists`: Require for L0, provide to L1
 

docs/designs/qemu-deprivilege.md

@@ -22,7 +22,7 @@ The following restrictions are currently implemented.
 '''Description''': As mentioned above, having QEMU switch to a
 non-root user, one per domain id.  Not being the root user limits what
 a compromised QEMU process can do to the system, and having one user
-per domain id limits what a comprimised QEMU process can do to the
+per domain id limits what a compromised QEMU process can do to the
 QEMU processes of other VMs.
 
 '''Implementation''': The toolstack adds the following to the qemu command-line:
@@ -79,8 +79,8 @@ Then adds the following to the qemu command-line:
 ## Namespaces for unused functionality (Linux only)
 
 '''Description''': QEMU doesn't use the functionality associated with
-mount and IPC namespaces. (IPC namespaces contol non-file-based IPC
-mechanisms within the kernel; unix and network sockets are not
+mount and IPC namespaces. (IPC namespaces control non-file-based IPC
+mechanisms within the kernel; Unix and network sockets are not
 affected by this.)  Making separate namespaces for these for QEMU
 won't affect normal operation, but it does mean that even if other
 restrictions fail, the process won't be able to even name system mount
@@ -179,7 +179,7 @@ being killed by the target process:
             kill(-1, 9);
     }
 
-Fortunately there is an assymetry we can take advantage of.  From the
+Fortunately there is an asymmetry we can take advantage of.  From the
 POSIX spec:
 
 > For a process to have permission to send a signal to a process
@@ -220,7 +220,7 @@ RLIMIT_NPROC limits total number of processes or threads.  QEMU uses
 threads for some devices, so this would require some thought.
 
 Other things that would take some cleverness / changes to QEMU to
-utilize due to ordering constrants:
+utilize due to ordering constraints:
  - RLIMIT_NOFILES (after all necessary files are opened)
 
 ## libxl: Treat QMP connection as untrusted
@@ -251,7 +251,7 @@ executing QEMU.  (But this would then require other changes to create
 the QMP socket, VNC socket, and so on).
 
 It should be noted that `-sandbox` is implemented as a blacklist, not
-a whitelist; that is, it disables known-unsed functionality which may
+a whitelist; that is, it disables known-unused functionality which may
 be harmful, rather than disabling all functionality except that known
 to be safe and needed.  This is unfortunately necessary since qemu
 doesn't know what system calls libraries might end up making.  (See

docs/designs/xenstore-migration.md

@@ -372,7 +372,7 @@ or modified by a transaction for which there is also a `TRANSACTION_DATA`
 record previously present).
 
 Each _committed_ node in the stream is required to have an already known parent
-node. A parent node is known if it was either in the node data base before the
+node. A parent node is known if it was either in the node database before the
 stream was started to be processed, or if a `NODE_DATA` record for that parent
 node has already been processed in the stream.
 

docs/features/qemu-deprivilege.pandoc

@@ -25,7 +25,7 @@ dm_restrict is a set of operations to restrict QEMU running in domain
 
  1. Mechanisms to restrict QEMU to only being able to affect its own
 domain
- 2. Mechanisms to restruct QEMU's ability to interact with domain 0.
+ 2. Mechanisms to restrict QEMU's ability to interact with domain 0.
 
 # User details