docs/: fix some comment spelling errors

I found that there are many spelling errors in the comments of qemu,
so I used the spellcheck tool to check the spelling errors
and finally found some spelling errors in the docs folder.

Signed-off-by: zhaolichang <zhaolichang@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200917075029.313-4-zhaolichang@huawei.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>

5 files changed, 7 insertions, 7 deletions

diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst
index c20bd37..059ad67 100644
--- a/docs/interop/bitmaps.rst
+++ b/docs/interop/bitmaps.rst
@@ -484,7 +484,7 @@ Bitmaps can generally be modified at any time, but certain operations often
 only make sense when paired directly with other commands. When a VM is paused,
 it's easy to ensure that no guest writes occur between individual QMP
 commands. When a VM is running, this is difficult to accomplish with
-individual QMP commands that may allow guest writes to occur inbetween each
+individual QMP commands that may allow guest writes to occur between each
 command.
 
 For example, using only individual QMP commands, we could:
diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
index 76a5bde..be596d3 100644
--- a/docs/interop/dbus.rst
+++ b/docs/interop/dbus.rst
@@ -57,7 +57,7 @@ Depending on the use case, you may choose different scenarios:
  - Everything the same UID
 
    - Convenient for developers
-   - Improved reliability - crash of one part doens't take
+   - Improved reliability - crash of one part doesn't take
      out entire VM
    - No security benefit over traditional QEMU, unless additional
      unless additional controls such as SELinux or AppArmor are
@@ -87,7 +87,7 @@ For example, to allow only ``qemu`` user to talk to ``qemu-helper``
   </policy>
 
 
-dbus-daemon can also perfom SELinux checks based on the security
+dbus-daemon can also perform SELinux checks based on the security
 context of the source and the target. For example, ``virtiofs_t``
 could be allowed to send a message to ``svirt_t``, but ``virtiofs_t``
 wouldn't be allowed to send a message to ``virtiofs_t``.
diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index 4511880..f3b3cac 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -53,5 +53,5 @@ the operation of that feature.
 * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
 * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
 NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
-* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports,
+* 4.2: NBD_FLAG_CAN_MULTI_CONN for shareable read-only exports,
 NBD_CMD_FLAG_FAST_ZERO
diff --git a/docs/interop/vhost-user-gpu.rst b/docs/interop/vhost-user-gpu.rst
index 688f8b4..3268bf4 100644
--- a/docs/interop/vhost-user-gpu.rst
+++ b/docs/interop/vhost-user-gpu.rst
@@ -66,7 +66,7 @@ VhostUserGpuCursorPos
 
 :scanout-id: ``u32``, the scanout where the cursor is located
 
-:x/y: ``u32``, the cursor postion
+:x/y: ``u32``, the cursor position
 
 VhostUserGpuCursorUpdate
 ^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 10e3e34..988f154 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -464,7 +464,7 @@ the ``VHOST_USER_SET_MEM_TABLE`` request. For invalidation events, the
 (3), the I/O virtual address and the size. On success, the slave is
 expected to reply with a zero payload, non-zero otherwise.
 
-The slave relies on the slave communcation channel (see :ref:`Slave
+The slave relies on the slave communication channel (see :ref:`Slave
 communication <slave_communication>` section below) to send IOTLB miss
 and access failure events, by sending ``VHOST_USER_SLAVE_IOTLB_MSG``
 requests to the master with a ``struct vhost_iotlb_msg`` as
@@ -1450,7 +1450,7 @@ vhost-user backends can provide various devices & services and may
 need to be configured manually depending on the use case. However, it
 is a good idea to follow the conventions listed here when
 possible. Users, QEMU or libvirt, can then rely on some common
-behaviour to avoid heterogenous configuration and management of the
+behaviour to avoid heterogeneous configuration and management of the
 backend programs and facilitate interoperability.
 
 Each backend installed on a host system should come with at least one