diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index 43010227e5..cbd63d0af8 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -539,13 +539,13 @@ The type definition of the function are as follow:
 ### .livepatch.xen_depends, .livepatch.depends and .note.gnu.build-id
 
 To support dependencies checking and safe loading (to load the
-appropiate payload against the right hypervisor) there is a need
-to embbed an build-id dependency.
+appropriate payload against the right hypervisor) there is a need
+to embed a build-id dependency.
 
 This is done by the payload containing sections `.livepatch.xen_depends`
 and `.livepatch.depends` which follow the format of an ELF Note.
 The contents of these (name, and description) are specific to the linker
-utilized to build the hypevisor and payload.
+utilized to build the hypervisor and payload.
 
 If GNU linker is used then the name is `GNU` and the description
 is a NT_GNU_BUILD_ID type ID. The description can be an SHA1
@@ -639,7 +639,7 @@ The `name` could be an UUID that stays fixed forever for a given
 payload. It can be embedded into the ELF payload at creation time
 and extracted by tools.
 
-The return value is zero if the payload was succesfully uploaded.
+The return value is zero if the payload was successfully uploaded.
 Otherwise an -XEN_EXX return value is provided. Duplicate `name` are not supported.
 
 The `payload` is the ELF payload as mentioned in the `Payload format` section.
diff --git a/docs/misc/netif-staging-grants.pandoc b/docs/misc/netif-staging-grants.pandoc
index cb33028adc..d7ef4db63a 100644
--- a/docs/misc/netif-staging-grants.pandoc
+++ b/docs/misc/netif-staging-grants.pandoc
@@ -317,7 +317,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
  process the actual like the steps below. This thread has the purpose of
  aggregating as much copies as possible.]
 
-2) Checks if there are enough rx ring slots that can accomodate the packet.
+2) Checks if there are enough rx ring slots that can accommodate the packet.
 
 3) Gets a request from the ring for the first data slot and fetches the `gref`
    from it.
@@ -375,7 +375,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
 
 24) Call packet into the network stack.
 
-25) Allocate new pages and any necessary packet metadata strutures to new
+25) Allocate new pages and any necessary packet metadata structures to new
     requests. These requests will then be used in step 1) and so forth.
 
 26) Update the request producer index (`req_prod`)
@@ -391,7 +391,7 @@ In essence the steps for receiving of a packet in a Linux frontend is as
 
 This proposal aims at replacing step 4), 12) and  22) with memcpy if the
 grefs on the Rx ring were requested to be mapped by the guest. Frontend may use
-strategies to allow fast recycling of grants for replinishing the ring,
+strategies to allow fast recycling of grants for replenishing the ring,
 hence letting Domain-0 replace the grant copies with  memcpy instead, which is
 faster.
 
@@ -400,8 +400,8 @@ would need to aggregate as much as grant ops as possible (step 1) and could
 transmit the packet on the transmit function (e.g. Linux ```ndo_start_xmit```)
 as previously proposed
 here\[[0](http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg01504.html)\].
-This would heavily improve efficiency specifially for smaller packets. Which in
-return would decrease RTT, having data being acknoledged much quicker.
+This would heavily improve efficiency specifically for smaller packets. Which in
+return would decrease RTT, having data being acknowledged much quicker.
 
 \clearpage
 
diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
index 8f666f696a..ce32829dae 100644
--- a/docs/misc/printk-formats.txt
+++ b/docs/misc/printk-formats.txt
@@ -11,7 +11,7 @@ Raw buffer as hex string:
        %*phN   000102 ... 3f
 
        Up to 64 characters.  Buffer length expected via the field_width
-       paramter. i.e. printk("%*ph", 8, buffer);
+       parameter. i.e. printk("%*ph", 8, buffer);
 
 Bitmaps (e.g. cpumask/nodemask):
 
