diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc
index e18aacea7c..cd854d2a7a 100644
--- a/docs/designs/argo.pandoc
+++ b/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.
 
diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md
index 837a96df05..c855748141 100644
--- a/docs/designs/nested-svm-cpu-features.md
+++ b/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.
diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md
index f12b1a3ae3..603491f24d 100644
--- a/docs/designs/qemu-deprivilege.md
+++ b/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
@@ -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
diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md
index 5022268386..082314bf72 100644
--- a/docs/designs/xenstore-migration.md
+++ b/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.
 
diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-deprivilege.pandoc
index 4ef119c821..915e38d8c9 100644
--- a/docs/features/qemu-deprivilege.pandoc
+++ b/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
 
