Fix some typos in documentation (found by codespell)

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <20211117210702.1393570-1-sw@weilnetz.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[thuth: "what's" --> "what is" as suggested by philmd]
Signed-off-by: Thomas Huth <thuth@redhat.com>

diff --git a/docs/devel/multi-process.rst b/docs/devel/multi-process.rst
index e5758a79abaedc84d510c43f3ee45c23ac7545a6..5c857ff3b90572bde8335fa11a3aca7cba2ae528 100644 (file)
--- a/docs/devel/multi-process.rst
+++ b/docs/devel/multi-process.rst
@@ -641,7 +641,7 @@ the CPU that issued the MMIO.
 +==========+========================+
 | rid      | range MMIO is within   |
 +----------+------------------------+
-| offset   | offset withing *rid*   |
+| offset   | offset within *rid*    |
 +----------+------------------------+
 | type     | e.g., load or store    |
 +----------+------------------------+

diff --git a/docs/devel/qgraph.rst b/docs/devel/qgraph.rst
index db44d710027a41cfb5fb0c965308fb9ce302f136..43342d9d6505e69a4aac4036c3f4afc2c22b4a39 100644 (file)
--- a/docs/devel/qgraph.rst
+++ b/docs/devel/qgraph.rst
@@ -14,7 +14,7 @@ support that device.
 Using only libqos APIs, the test has to manually take care of
 covering all the setups, and build the correct command line.
 
-This also introduces backward compability issues: if a device/driver command
+This also introduces backward compatibility issues: if a device/driver command
 line name is changed, all tests that use that will not work
 properly anymore and need to be adjusted.
 

diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
index b3e2c8481d4be04641626d66cdc175c655e3a47a..1693822f8f93cb68e4d31a6002b12ad06a2998e3 100644 (file)
--- a/docs/devel/writing-monitor-commands.rst
+++ b/docs/devel/writing-monitor-commands.rst
@@ -677,7 +677,7 @@ return a single text string::
 
 The ``HumanReadableText`` struct is intended to be used for all
 commands, under the ``x-`` name prefix that are returning unstructured
-text targetted at humans. It should never be used for commands outside
+text targeted at humans. It should never be used for commands outside
 the ``x-`` name prefix, as those should be using structured QAPI types.
 
 Implementing the QMP command

diff --git a/docs/hyperv.txt b/docs/hyperv.txt
index 5d99fd9a72b83ae9dd638eb332159f14ce7aca91..0417c183a3b06442b92fdf90850850ec6e6268e6 100644 (file)
--- a/docs/hyperv.txt
+++ b/docs/hyperv.txt
@@ -195,7 +195,7 @@ The enlightenment allows to use Hyper-V SynIC with hardware APICv/AVIC enabled.
 Normally, Hyper-V SynIC disables these hardware feature and suggests the guest
 to use paravirtualized AutoEOI feature.
 Note: enabling this feature on old hardware (without APICv/AVIC support) may
-have negative effect on guest's performace.
+have negative effect on guest's performance.
 
 3.19. hv-no-nonarch-coresharing=on/off/auto
 ===========================================

diff --git a/docs/system/cpu-models-x86.rst.inc b/docs/system/cpu-models-x86.rst.inc
index 6e8be7d79b1029c676a4ac003d859026071eb1cf..7f6368f999b10dc943c0c084e4b3253834674c46 100644 (file)
--- a/docs/system/cpu-models-x86.rst.inc
+++ b/docs/system/cpu-models-x86.rst.inc
@@ -49,7 +49,7 @@ future OS and toolchains are likely to target newer ABIs. The
 table that follows illustrates which ABI compatibility levels
 can be satisfied by the QEMU CPU models. Note that the table only
 lists the long term stable CPU model versions (eg Haswell-v4).
-In addition to whats listed, there are also many CPU model
+In addition to what is listed, there are also many CPU model
 aliases which resolve to a different CPU model version,
 depending on the machine type is in use.
 

diff --git a/docs/system/devices/nvme.rst b/docs/system/devices/nvme.rst
index a1c0db01f6d5fddeebac561539f9e17e04a9fe78..b5acb2a9c19dab27264a2bc650237425674c7b3f 100644 (file)
--- a/docs/system/devices/nvme.rst
+++ b/docs/system/devices/nvme.rst
@@ -70,7 +70,7 @@ namespaces and additional features, the ``nvme-ns`` device must be used.
 
 The namespaces defined by the ``nvme-ns`` device will attach to the most
 recently defined ``nvme-bus`` that is created by the ``nvme`` device. Namespace
-identifers are allocated automatically, starting from ``1``.
+identifiers are allocated automatically, starting from ``1``.
 
 There are a number of parameters available:
 

diff --git a/docs/system/gdb.rst b/docs/system/gdb.rst
index bdb42dae2fe97172a682bc013b4ca1593e4010fb..453eb73f6c43b03c06d46de91e1aca61c3fa043a 100644 (file)
--- a/docs/system/gdb.rst
+++ b/docs/system/gdb.rst
@@ -56,7 +56,7 @@ machine has more than one CPU, QEMU exposes each CPU cluster as a
 separate "inferior", where each CPU within the cluster is a separate
 "thread". Most QEMU machine types have identical CPUs, so there is a
 single cluster which has all the CPUs in it.  A few machine types are
-heterogenous and have multiple clusters: for example the ``sifive_u``
+heterogeneous and have multiple clusters: for example the ``sifive_u``
 machine has a cluster with one E51 core and a second cluster with four
 U54 cores. Here the E51 is the only thread in the first inferior, and
 the U54 cores are all threads in the second inferior.

diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst
index afc58f60f522fd58628af02a68f30c9b70576b95..9beef391717a618f47dea502ee688baa5adcab8e 100644 (file)
--- a/docs/system/ppc/ppce500.rst
+++ b/docs/system/ppc/ppce500.rst
@@ -75,7 +75,7 @@ as the BIOS. QEMU follows below truth table to select which payload to execute:
 When both -bios and -kernel are present, QEMU loads U-Boot and U-Boot in turns
 automatically loads the kernel image specified by the -kernel parameter via
 U-Boot's built-in "bootm" command, hence a legacy uImage format is required in
-such senario.
+such scenario.
 
 Running Linux kernel
 --------------------

diff --git a/docs/system/riscv/shakti-c.rst b/docs/system/riscv/shakti-c.rst
index a6035d42b0da089d943bab14efbec4569255c57b..fea57f7b6ba0c990e7e07447929a3a21f4d4828c 100644 (file)
--- a/docs/system/riscv/shakti-c.rst
+++ b/docs/system/riscv/shakti-c.rst
@@ -45,7 +45,7 @@ Shakti SDK can be used to generate the baremetal example UART applications.
 Binary would be generated in:
   software/examples/uart_applns/loopback/output/loopback.shakti
 
-You could also download the precompiled example applicatons using below
+You could also download the precompiled example applications using below
 commands.
 
 .. code-block:: bash