Re: [PATCH for-5.2] docs: Fix some typos (found by codespell)

[Michael S. Tsirkin]

On Tue, Nov 17, 2020 at 08:34:48PM +0100, Stefan Weil wrote:
> Fix also a similar typo in a code comment.
> 
> Signed-off-by: Stefan Weil <sw@weilnetz.de>

Reviewed-by: Michael S. Tsirkin <mst@redhat.com>

> ---
>  docs/can.txt                  | 8 ++++----
>  docs/interop/vhost-user.rst   | 2 +-
>  docs/replay.txt               | 2 +-
>  docs/specs/ppc-spapr-numa.rst | 2 +-
>  docs/system/deprecated.rst    | 4 ++--
>  docs/tools/virtiofsd.rst      | 2 +-
>  hw/vfio/igd.c                 | 2 +-
>  7 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/docs/can.txt b/docs/can.txt
> index 5838f6620c..0d310237df 100644
> --- 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 988f154144..72b2e8c7ba 100644
> --- a/docs/interop/vhost-user.rst
> +++ b/docs/interop/vhost-user.rst
> @@ -513,7 +513,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 87a64ae068..5b008ca491 100644
> --- 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 5fca2bdd8e..ffa687dc89 100644
> --- 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 32a0e620db..63e9db1463 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -465,7 +465,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.
>  
> @@ -637,7 +637,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 34a9e40146..866b7db3ee 100644
> --- 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 64e332746b..470205f487 100644
> --- 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.
> -- 
> 2.29.2