docs: Fix some typos (found by codespell)

Fix also a similar typo in a code comment.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <20201117193448.393472-1-sw@weilnetz.de>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

diff --git a/docs/can.txt b/docs/can.txt
index 5838f6620c24149259ff75b9921948d2a2e18547..0d310237dfaadaed4e69f01295e98b6c9dda527c 100644 (file)
--- a/docs/can.txt
+++ b/docs/can.txt
@@ -19,7 +19,7 @@ interface to implement because such device can be easily connected
 to systems with different CPU architectures (x86, PowerPC, Arm, etc.).
 
 In 2020, CTU CAN FD controller model has been added as part
-of the bachelor theses of Jan Charvat. This controller is complete
+of the bachelor thesis of Jan Charvat. This controller is complete
 open-source/design/hardware solution. The core designer
 of the project is Ondrej Ille, the financial support has been
 provided by CTU, and more companies including Volkswagen subsidiaries.
@@ -31,7 +31,7 @@ testing lead to goal change to provide environment which provides complete
 emulated environment for testing and RTEMS GSoC slot has been donated
 to work on CAN hardware emulation on QEMU.
 
-Examples how to use CAN emulation for SJA1000 based borads
+Examples how to use CAN emulation for SJA1000 based boards
 ==========================================================
 
 When QEMU with CAN PCI support is compiled then one of the next
@@ -106,8 +106,8 @@ This open-source core provides CAN FD support. CAN FD drames are
 delivered even to the host systems when SocketCAN interface is found
 CAN FD capable.
 
-The PCIe borad emulation is provided for now (the device identifier is
-ctucan_pci). The defauld build defines two CTU CAN FD cores
+The PCIe board emulation is provided for now (the device identifier is
+ctucan_pci). The default build defines two CTU CAN FD cores
 on the board.
 
 Example how to connect the canbus0-bus (virtual wire) to the host

diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 6d4025ba6a37eb2adeb06216bdadbf86b909a912..d6085f7045222193c930a2779fe5215047856675 100644 (file)
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -530,7 +530,7 @@ descriptor table (split virtqueue) or descriptor ring (packed
 virtqueue). However, it can't work when we process descriptors
 out-of-order because some entries which store the information of
 inflight descriptors in available ring (split virtqueue) or descriptor
-ring (packed virtqueue) might be overrided by new entries. To solve
+ring (packed virtqueue) might be overridden by new entries. To solve
 this problem, slave need to allocate an extra buffer to store this
 information of inflight descriptors and share it with master for
 persistent. ``VHOST_USER_GET_INFLIGHT_FD`` and

diff --git a/docs/replay.txt b/docs/replay.txt
index 87a64ae068d54d282d914d79bcaa08f0908410be..5b008ca4911f72204ec84e393dd5cbddded4bce2 100644 (file)
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -328,7 +328,7 @@ between the snapshots. Each of the passes include the following steps:
  1. loading the snapshot
  2. replaying to examine the breakpoints
  3. if breakpoint or watchpoint was met
-    - loading the snaphot again
+    - loading the snapshot again
     - replaying to the required breakpoint
  4. else
     - proceeding to the p.1 with the earlier snapshot

diff --git a/docs/specs/ppc-spapr-numa.rst b/docs/specs/ppc-spapr-numa.rst
index 5fca2bdd8efe238c84a6d581b30bf10d87c83d76..ffa687dc89da79e2e01ecad6f3beb85b2266db67 100644 (file)
--- a/docs/specs/ppc-spapr-numa.rst
+++ b/docs/specs/ppc-spapr-numa.rst
@@ -198,7 +198,7 @@ This is how it is being done:
 * user distance 121 and beyond will be interpreted as 160
 * user distance 10 stays 10
 
-The reasoning behind this aproximation is to avoid any round up to the local
+The reasoning behind this approximation is to avoid any round up to the local
 distance (10), keeping it exclusive to the 4th NUMA level (which is still
 exclusive to the node_id). All other ranges were chosen under the developer
 discretion of what would be (somewhat) sensible considering the user input.

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index bbaae0d97c3b84d41141f3003649e7b2d3bd988c..d98464098f570bff4c5d2eb8c6b3998fce8bcde5 100644 (file)
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -473,7 +473,7 @@ default configuration.
 
 The CPU model runnability guarantee won't apply anymore to
 existing CPU models.  Management software that needs runnability
-guarantees must resolve the CPU model aliases using te
+guarantees must resolve the CPU model aliases using the
 ``alias-of`` field returned by the ``query-cpu-definitions`` QMP
 command.
 
@@ -660,7 +660,7 @@ Splitting RAM by default between NUMA nodes had the same issues as ``mem``
 parameter with the difference that the role of the user plays QEMU using
 implicit generic or board specific splitting rule.
 Use ``memdev`` with *memory-backend-ram* backend or ``mem`` (if
-it's supported by used machine type) to define mapping explictly instead.
+it's supported by used machine type) to define mapping explicitly instead.
 Users of existing VMs, wishing to preserve the same RAM distribution, should
 configure it explicitly using ``-numa node,memdev`` options. Current RAM
 distribution can be retrieved using HMP command ``info numa`` and if separate

diff --git a/docs/tools/virtiofsd.rst b/docs/tools/virtiofsd.rst
index 34a9e40146434026077d846033e4158859dd73e3..866b7db3eed36302bc96bbef8184e87fdc9df9b9 100644 (file)
--- a/docs/tools/virtiofsd.rst
+++ b/docs/tools/virtiofsd.rst
@@ -174,7 +174,7 @@ Using ':' as the separator a rule is of the form:
 - 'bad' - If a client tries to use a name matching 'key' it's
   denied using EPERM; when the server passes an attribute
   name matching 'prepend' it's hidden.  In many ways it's use is very like
-  'ok' as either an explict terminator or for special handling of certain
+  'ok' as either an explicit terminator or for special handling of certain
   patterns.
 
 **key** is a string tested as a prefix on an attribute name originating

diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c
index 64e332746b49cd26840339006db2bb2d26305954..470205f487eb7894c157e4ab6a5063cc841d1f49 100644 (file)
--- a/hw/vfio/igd.c
+++ b/hw/vfio/igd.c
@@ -535,7 +535,7 @@ void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr)
     }
 
     /*
-     * Assume we have no GMS memory, but allow it to be overrided by device
+     * Assume we have no GMS memory, but allow it to be overridden by device
      * option (experimental).  The spec doesn't actually allow zero GMS when
      * when IVD (IGD VGA Disable) is clear, but the claim is that it's unused,
      * so let's not waste VM memory for it.