summary refs log tree commit diff stats
path: root/docs/interop
diff options
context:
space:
mode:
Diffstat (limited to 'docs/interop')
-rw-r--r--docs/interop/bitmaps.rst2
-rw-r--r--docs/interop/dbus.rst4
-rw-r--r--docs/interop/nbd.txt2
-rw-r--r--docs/interop/vhost-user-gpu.rst2
-rw-r--r--docs/interop/vhost-user.rst4
5 files changed, 7 insertions, 7 deletions
diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst
index c20bd37a79..059ad67929 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 76a5bde625..be596d3f41 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 4511880961..f3b3cacc96 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 688f8b4259..3268bf405c 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 10e3e3475e..988f154144 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