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>
This commit is contained in:
Ville Skyttä 2018-06-12 09:51:50 +03:00 committed by Peter Maydell
parent 68f1b569dc
commit 9277d81f5c
18 changed files with 22 additions and 21 deletions

View File

@ -145,7 +145,7 @@ and redirect indev's packet to filter.
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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -37,7 +37,7 @@ over any transport.
- 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

View File

@ -316,7 +316,7 @@ other cores sharing access to the memory. The classic example is the
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

View File

@ -326,8 +326,8 @@ in the image file.
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 @@ The L1 table has a variable size (stored in the header) and may use multiple
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))

View File

@ -108,12 +108,12 @@ Depending on the request type, payload can be:
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

View File

@ -62,7 +62,7 @@ It's also possible to start a guest with memory cold-plugged into the
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:

View File

@ -62,7 +62,7 @@ to its own window so you can see both display devices side-by-side.
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

View File

@ -524,7 +524,7 @@ You can create a cloned image from the existing snapshot.
@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:

View File

@ -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.

View File

@ -72,7 +72,8 @@ for NVDIMM ACPI.
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

View File

@ -10,7 +10,7 @@ calls which are mostly used as a private interface between the firmware
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)

View File

@ -252,7 +252,7 @@ swtpm socket --tpmstate dir=/tmp/mytpm1 \
--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 \

View File

@ -41,7 +41,7 @@ the PIIX3 chipset. The USB 1.1 bus will carry the name "usb-bus.0".
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".