docs: Grammar and spelling fixes
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180612065150.21110-1-ville.skytta@iki.fi
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
diff --git a/docs/colo-proxy.txt b/docs/colo-proxy.txt
index 8b726ea..1f8e4b4 100644
--- a/docs/colo-proxy.txt
+++ b/docs/colo-proxy.txt
@@ -145,7 +145,7 @@
COLO-compare, we do packet comparing job.
Packets coming from the primary char indev will be sent to outdev.
Packets coming from the secondary char dev will be dropped after comparing.
-COLO-comapre need two input chardev and one output chardev:
+COLO-compare needs two input chardevs and one output chardev:
primary_in=chardev1-id (source: primary send packet)
secondary_in=chardev2-id (source: secondary send packet)
outdev=chardev3-id
diff --git a/docs/config/mach-virt-graphical.cfg b/docs/config/mach-virt-graphical.cfg
index 0fdf684..d6d31b1 100644
--- a/docs/config/mach-virt-graphical.cfg
+++ b/docs/config/mach-virt-graphical.cfg
@@ -185,7 +185,7 @@
# attached to it.
#
# We also create an optical disk, mostly for installation
-# purposes: once the guest OS has been succesfully
+# purposes: once the guest OS has been successfully
# installed, the guest will no longer boot from optical
# media. If you don't want, or no longer want, to have an
# optical disk in the guest you can safely comment out
diff --git a/docs/config/mach-virt-serial.cfg b/docs/config/mach-virt-serial.cfg
index aee9f1c..18a7c83 100644
--- a/docs/config/mach-virt-serial.cfg
+++ b/docs/config/mach-virt-serial.cfg
@@ -191,7 +191,7 @@
# attached to it.
#
# We also create an optical disk, mostly for installation
-# purposes: once the guest OS has been succesfully
+# purposes: once the guest OS has been successfully
# installed, the guest will no longer boot from optical
# media. If you don't want, or no longer want, to have an
# optical disk in the guest you can safely comment out
diff --git a/docs/config/q35-emulated.cfg b/docs/config/q35-emulated.cfg
index c6416d6..99ac918 100644
--- a/docs/config/q35-emulated.cfg
+++ b/docs/config/q35-emulated.cfg
@@ -130,7 +130,7 @@
# it to that controller so that the guest can use it.
#
# We also create an optical disk, mostly for installation
-# purposes: once the guest OS has been succesfully
+# purposes: once the guest OS has been successfully
# installed, the guest will no longer boot from optical
# media. If you don't want, or no longer want, to have an
# optical disk in the guest you can safely comment out
diff --git a/docs/config/q35-virtio-graphical.cfg b/docs/config/q35-virtio-graphical.cfg
index 28bde2f..4207f11 100644
--- a/docs/config/q35-virtio-graphical.cfg
+++ b/docs/config/q35-virtio-graphical.cfg
@@ -136,7 +136,7 @@
# attached to it.
#
# We also create an optical disk, mostly for installation
-# purposes: once the guest OS has been succesfully
+# purposes: once the guest OS has been successfully
# installed, the guest will no longer boot from optical
# media. If you don't want, or no longer want, to have an
# optical disk in the guest you can safely comment out
diff --git a/docs/config/q35-virtio-serial.cfg b/docs/config/q35-virtio-serial.cfg
index c33c9cc..d2830ae 100644
--- a/docs/config/q35-virtio-serial.cfg
+++ b/docs/config/q35-virtio-serial.cfg
@@ -141,7 +141,7 @@
# attached to it.
#
# We also create an optical disk, mostly for installation
-# purposes: once the guest OS has been succesfully
+# purposes: once the guest OS has been successfully
# installed, the guest will no longer boot from optical
# media. If you don't want, or no longer want, to have an
# optical disk in the guest you can safely comment out
diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
index 40f136f..6ed3fce 100644
--- a/docs/devel/migration.rst
+++ b/docs/devel/migration.rst
@@ -37,7 +37,7 @@
- tcp migration: do the migration using tcp sockets
- unix migration: do the migration using unix sockets
- exec migration: do the migration using the stdin/stdout through a process.
-- fd migration: do the migration using an file descriptor that is
+- fd migration: do the migration using a file descriptor that is
passed to QEMU. QEMU doesn't care how this file descriptor is opened.
In addition, support is included for migration using RDMA, which
diff --git a/docs/devel/multi-thread-tcg.txt b/docs/devel/multi-thread-tcg.txt
index 06530be..782bebc 100644
--- a/docs/devel/multi-thread-tcg.txt
+++ b/docs/devel/multi-thread-tcg.txt
@@ -316,7 +316,7 @@
x86 cmpxchg instruction.
The second type offer a pair of load/store instructions which offer a
-guarantee that an region of memory has not been touched between the
+guarantee that a region of memory has not been touched between the
load and store instructions. An example of this is ARM's ldrex/strex
pair where the strex instruction will return a flag indicating a
successful store only if no other CPU has accessed the memory region
diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index 8e1547d..845d40a 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -326,8 +326,8 @@
It contains pointers to the second level structures which are called refcount
blocks and are exactly one cluster in size.
-Given a offset into the image file, the refcount of its cluster can be obtained
-as follows:
+Given an offset into the image file, the refcount of its cluster can be
+obtained as follows:
refcount_block_entries = (cluster_size * 8 / refcount_bits)
@@ -365,7 +365,7 @@
clusters, however it must be contiguous in the image file. L2 tables are
exactly one cluster in size.
-Given a offset into the virtual disk, the offset into the image file can be
+Given an offset into the virtual disk, the offset into the image file can be
obtained as follows:
l2_entries = (cluster_size / sizeof(uint64_t))
diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index d51fd58..f59667f 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -108,12 +108,12 @@
IOVA: a 64-bit I/O virtual address programmed by the guest
Size: a 64-bit size
User address: a 64-bit user address
- Permissions: a 8-bit value:
+ Permissions: an 8-bit value:
- 0: No access
- 1: Read access
- 2: Write access
- 3: Read/Write access
- Type: a 8-bit IOTLB message type:
+ Type: an 8-bit IOTLB message type:
- 1: IOTLB miss
- 2: IOTLB update
- 3: IOTLB invalidate
diff --git a/docs/memory-hotplug.txt b/docs/memory-hotplug.txt
index d96397c..6aa5e17 100644
--- a/docs/memory-hotplug.txt
+++ b/docs/memory-hotplug.txt
@@ -62,7 +62,7 @@
hotpluggable memory slots. This might seem counterintuitive at first,
but this allows for a lot of flexibility when using the file backend.
-In the following command-line example, a 8GB guest is created where 6GB
+In the following command-line example, an 8GB guest is created where 6GB
comes from regular RAM, 1GB is a 1GB hugepage page and 256MB is from
2MB pages. Also, the guest has additional memory slots to hotplug more
2GB if needed:
diff --git a/docs/multiseat.txt b/docs/multiseat.txt
index dc28cdb..8dde36c 100644
--- a/docs/multiseat.txt
+++ b/docs/multiseat.txt
@@ -62,7 +62,7 @@
For vnc some additional configuration on the command line is needed.
We'll create two vnc server instances, and bind the second one to the
-second seat, simliar to input devices:
+second seat, similar to input devices:
-display vnc=:1,id=primary \
-display vnc=:2,id=secondary,display=video.2
diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi
index f179369..38e9f34 100644
--- a/docs/qemu-block-drivers.texi
+++ b/docs/qemu-block-drivers.texi
@@ -524,7 +524,7 @@
@example
qemu-img create -b sheepdog:///@var{base}#@var{tag} sheepdog:///@var{image}
@end example
-where @var{base} is a image name of the source snapshot and @var{tag}
+where @var{base} is an image name of the source snapshot and @var{tag}
is its tag name.
You can use an unix socket instead of an inet socket:
diff --git a/docs/qemupciserial.inf b/docs/qemupciserial.inf
index 6f7eef4..7ca7667 100644
--- a/docs/qemupciserial.inf
+++ b/docs/qemupciserial.inf
@@ -1,7 +1,7 @@
; qemupciserial.inf for QEMU, based on MSPORTS.INF
; The driver itself is shipped with Windows (serial.sys). This is
-; just a inf file to tell windows which pci id the serial pci card
+; just an inf file to tell windows which pci id the serial pci card
; emulated by qemu has, and to apply a name tag to it which windows
; will show in the device manager.
diff --git a/docs/specs/acpi_nvdimm.txt b/docs/specs/acpi_nvdimm.txt
index 3f322e6..3ec42ec 100644
--- a/docs/specs/acpi_nvdimm.txt
+++ b/docs/specs/acpi_nvdimm.txt
@@ -72,7 +72,8 @@
Memory:
QEMU uses BIOS Linker/loader feature to ask BIOS to allocate a memory
- page and dynamically patch its into a int32 object named "MEMA" in ACPI.
+ page and dynamically patch its address into an int32 object named "MEMA"
+ in ACPI.
This page is RAM-based and it is used to transfer data between _DSM
method and QEMU. If ACPI has control, this pages is owned by ACPI which
diff --git a/docs/specs/ppc-spapr-hcalls.txt b/docs/specs/ppc-spapr-hcalls.txt
index 5bd8eab..93fe3da 100644
--- a/docs/specs/ppc-spapr-hcalls.txt
+++ b/docs/specs/ppc-spapr-hcalls.txt
@@ -10,7 +10,7 @@
running in the guest and QEMU.
All those hypercalls start at hcall number 0xf000 which correspond
-to a implementation specific range in PAPR.
+to an implementation specific range in PAPR.
- H_RTAS (0xf000)
diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
index 70ad4a0..0e9bbeb 100644
--- a/docs/specs/tpm.txt
+++ b/docs/specs/tpm.txt
@@ -252,7 +252,7 @@
--ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock \
--log level=20 --tpm2
-In the 2nd terminal restore the state of the VM using the additonal
+In the 2nd terminal restore the state of the VM using the additional
'-incoming' option.
qemu-system-x86_64 -display sdl -accel kvm \
diff --git a/docs/usb2.txt b/docs/usb2.txt
index e2fa2cf..f63c8d9 100644
--- a/docs/usb2.txt
+++ b/docs/usb2.txt
@@ -41,7 +41,7 @@
You can use the standard -device switch to add a EHCI controller to
your virtual machine. It is strongly recommended to specify an ID for
-the controller so the USB 2.0 bus gets a individual name, for example
+the controller so the USB 2.0 bus gets an individual name, for example
'-device usb-ehci,id=ehci". This will give you a USB 2.0 bus named
"ehci.0".
