diff --git a/docs/colo-proxy.txt b/docs/colo-proxy.txt index 8b726ea09429107e798a5caa12d76e2f71da8f0a..1f8e4b4e77160f73a88d91982326d9f7ddae41b5 100644 --- a/docs/colo-proxy.txt +++ b/docs/colo-proxy.txt @@ -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 diff --git a/docs/config/mach-virt-graphical.cfg b/docs/config/mach-virt-graphical.cfg index 0fdf6846ddbf9529e8c0b8bb12c51687aa78b7de..d6d31b17f5943b9dfff6fb9ee085ae0b13273865 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 aee9f1c5a126c7004e5b292bc9449d4cc1b05fcf..18a7c837319fb92dd4a33545a116094550ccfaf4 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 c6416d65453c8783c4882713d43d7d523fe95d4e..99ac918e78a2553c0214dacf23d5de8668e869a0 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 28bde2fc57b9c049e9844026533024a965c4a96f..4207f11e4f178bfb0d4cacdadbfe6fd997ad8e1d 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 c33c9cc07a5c08277327cca8fd17225d8a5d6a4f..d2830aec5e647c8f2bbf8379729403ecdf6febd6 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 40f136f6be60717e551fea50c7694f6f5dcc43f3..6ed3fce061316b729cd1505ee1a520145e23e9d9 100644 --- a/docs/devel/migration.rst +++ b/docs/devel/migration.rst @@ -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 diff --git a/docs/devel/multi-thread-tcg.txt b/docs/devel/multi-thread-tcg.txt index 06530be1e98435cce8d59715831689978430bfec..782bebc28b41f7b209dbdefc82c3dc348d12a060 100644 --- a/docs/devel/multi-thread-tcg.txt +++ b/docs/devel/multi-thread-tcg.txt @@ -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 diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt index 8e1547ded27b1bb6da4007018fde09b24c5d8765..845d40a086d505b4ef6ee96ee78dfddf87d7cd13 100644 --- a/docs/interop/qcow2.txt +++ b/docs/interop/qcow2.txt @@ -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)) diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt index d51fd582423a2534b9100c745715b55c844c3b2f..f59667f49868bf938fe27a3fc94aec11178d2f69 100644 --- a/docs/interop/vhost-user.txt +++ b/docs/interop/vhost-user.txt @@ -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 diff --git a/docs/memory-hotplug.txt b/docs/memory-hotplug.txt index d96397c1afe27cb35148a7adf2f2cc40dd9f61d8..6aa5e17e26090f619787de7b71888093fb9d0117 100644 --- a/docs/memory-hotplug.txt +++ b/docs/memory-hotplug.txt @@ -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: diff --git a/docs/multiseat.txt b/docs/multiseat.txt index dc28cdb61342d50288e1d22da805b24e00723c0b..8dde36c8450cc8827449f9f88630ffec62664a2a 100644 --- a/docs/multiseat.txt +++ b/docs/multiseat.txt @@ -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 diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi index f1793692bb49d5d8ebc39095e46efbd422a7c289..38e9f34cc9b86d55c31d5abe02978ad5042d894f 100644 --- a/docs/qemu-block-drivers.texi +++ b/docs/qemu-block-drivers.texi @@ -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: diff --git a/docs/qemupciserial.inf b/docs/qemupciserial.inf index 6f7eef49cc97409d3a8f3e4fab7c4e89c2cc81e5..7ca766745dee68c1a6cf44355ed36737885bcf43 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 3f322e6f55b11b849278f61f1398ec4bc5de1139..3ec42ecbce4d589329c926058f4a990b634e756d 100644 --- a/docs/specs/acpi_nvdimm.txt +++ b/docs/specs/acpi_nvdimm.txt @@ -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 diff --git a/docs/specs/ppc-spapr-hcalls.txt b/docs/specs/ppc-spapr-hcalls.txt index 5bd8eab78f182a99ff6a14f2da27887c10119687..93fe3da91b166a1fdf8ac7c7356d677e5dc82145 100644 --- a/docs/specs/ppc-spapr-hcalls.txt +++ b/docs/specs/ppc-spapr-hcalls.txt @@ -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) diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt index 70ad4a0cba80d561226645ec00d8f1478e10c37d..0e9bbebe1d0569ff398eab3500d328b20e81da0a 100644 --- a/docs/specs/tpm.txt +++ b/docs/specs/tpm.txt @@ -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 \ diff --git a/docs/usb2.txt b/docs/usb2.txt index e2fa2cfde03c638a95ff403f7a7bdf4636defd37..f63c8d9465b515e097a6db4c15e26051e9cca784 100644 --- a/docs/usb2.txt +++ b/docs/usb2.txt @@ -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".