]> git.ipfire.org Git - thirdparty/qemu.git/commitdiff
doc: fix typos for documents in tree
authorLike Xu <like.xu@linux.intel.com>
Wed, 20 Feb 2019 05:27:26 +0000 (13:27 +0800)
committerLaurent Vivier <laurent@vivier.eu>
Wed, 6 Mar 2019 09:40:21 +0000 (10:40 +0100)
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <1550640446-18788-1-git-send-email-like.xu@linux.intel.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
docs/COLO-FT.txt
docs/amd-memory-encryption.txt
docs/can.txt
docs/colo-proxy.txt
docs/cpu-hotplug.rst
docs/qcow2-cache.txt
docs/qemu-block-drivers.texi
docs/qemu-cpu-models.texi
docs/rdma.txt
docs/replay.txt
docs/vfio-ap.txt

index e2686bb338826c9143a4d3b0bb30428d10fc037a..ad24680d130e86734d962c6a2701392862d88ba7 100644 (file)
@@ -102,7 +102,7 @@ to make sure the state of VM in Secondary side is always consistent with VM in
 Primary side.
 
 COLO Proxy:
-Delivers packets to Primary and Seconday, and then compare the responses from
+Delivers packets to Primary and Secondary, and then compare the responses from
 both side. Then decide whether to start a checkpoint according to some rules.
 Please refer to docs/colo-proxy.txt for more information.
 
index f483795eaafed8409b1e96806ca743354338c9dc..43bf3ee6a5a9fdd671376505aa9aa1c49557df79 100644 (file)
@@ -97,7 +97,7 @@ References
 AMD Memory Encryption whitepaper:
 http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
 
-Secure Encrypted Virutualization Key Management:
+Secure Encrypted Virtualization Key Management:
 [1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
 
 KVM Forum slides:
index 7ba23b259a48c41d8f5bddc3fd8621bd35316475..9fa6ed51c82351240bdbb8777fe141f846edb201 100644 (file)
@@ -99,7 +99,7 @@ Links to other resources
      https://gitlab.fel.cvut.cz/canbus/qemu-canbus
  (3) RTEMS page describing project
      https://devel.rtems.org/wiki/Developer/Simulators/QEMU/CANEmulation
- (4) RTLWS 2015 article about the projevt and its use with CANopen emulation
+ (4) RTLWS 2015 article about the project and its use with CANopen emulation
      http://rtime.felk.cvut.cz/publications/public/rtlws2015-qemu-can.pdf
      Slides
      http://rtime.felk.cvut.cz/publications/public/rtlws2015-qemu-can-slides.pdf
index 1f8e4b4e77160f73a88d91982326d9f7ddae41b5..fa1cef0278a5aaa014f9377b6ff179e18a69511f 100644 (file)
@@ -41,7 +41,7 @@ Below is a COLO proxy ascii figure:
 |         |  +------------------------------------------------------+  |                        |        |                              |
 |netfilter|  |                       |                         |    |  |   netfilter            |        |                              |
 | +----------+ +----------------------------+                  |    |  |  +-----------------------------------------------------------+ |
-| |       |  |                       |      |        out       |    |  |  |                     |        |  filter excute order       | |
+| |       |  |                       |      |        out       |    |  |  |                     |        |  filter execute order      | |
 | |       |  |          +-----------------------------+        |    |  |  |                     |        | +------------------->      | |
 | |       |  |          |            |      |         |        |    |  |  |                     |        |   TCP                      | |
 | | +-----+--+-+  +-----v----+ +-----v----+ |pri +----+----+sec|    |  |  | +------------+  +---+----+---v+rewriter++  +------------+ | |
@@ -53,7 +53,7 @@ Below is a COLO proxy ascii figure:
 | |      |   tx        |   rx           rx  |                  |  |    |  |            tx                        all       |  rx      | |
 | |      |             |                    |                  |  |    |  +-----------------------------------------------------------+ |
 | |      |             +--------------+     |                  |  |    |                                                   |            |
-| |      |   filter excute order      |     |                  |  |    |                                                   |            |
+| |      |   filter execute order     |     |                  |  |    |                                                   |            |
 | |      |  +---------------->        |     |                  |  +--------------------------------------------------------+            |
 | +-----------------------------------------+                  |       |                                                                |
 |        |                            |                        |       |                                                                |
@@ -92,7 +92,7 @@ but do nothing, just pass to next filter.
 
 Redirect Server Filter --> COLO-Compare
 COLO-compare receive primary guest packet then
-waiting scondary redirect packet to compare it.
+waiting secondary redirect packet to compare it.
 If packet same,send queued primary packet and clear
 queued secondary packet, Otherwise send primary packet
 and do checkpoint.
index 1c268e00b41a6b4e5af37571031ec89250ec0229..cfeb79f571113ffc06c32d89c0cfaa4a305ceccf 100644 (file)
@@ -137,6 +137,6 @@ From the 'qmp-shell', invoke the QMP ``device_del`` command::
     vCPU hot-unplug requires guest cooperation; so the ``device_del``
     command above does not guarantee vCPU removal -- it's a "request to
     unplug".  At this point, the guest will get a System Control
-    Interupt (SCI) and calls the ACPI handler for the affected vCPU
+    Interrupt (SCI) and calls the ACPI handler for the affected vCPU
     device.  Then the guest kernel will bring the vCPU offline and tell
     QEMU to unplug it.
index c459bf5dd3b5e157da15c71b31439be8710b292d..c1e7751feae649efe66f0d0b6d36dac89e0668c0 100644 (file)
@@ -55,7 +55,7 @@ value can improve the I/O performance significantly.
 
 The refcount blocks
 -------------------
-The qcow2 format also mantains a reference count for each cluster.
+The qcow2 format also maintains a reference count for each cluster.
 Reference counts are used for cluster allocation and internal
 snapshots. The data is stored in a two-level structure similar to the
 L1/L2 tables described above.
index 38e9f34cc9b86d55c31d5abe02978ad5042d894f..da06a9bc838d056d6295b0d1c50d5d05d84513f6 100644 (file)
@@ -632,7 +632,7 @@ qemu-system-i386 -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
 @end example
 
 
-Howto set up a simple iSCSI target on loopback and accessing it via QEMU:
+How to set up a simple iSCSI target on loopback and access it via QEMU:
 @example
 This example shows how to set up an iSCSI target with one CDROM and one DISK
 using the Linux STGT software target. This target is available on Red Hat based
index 475d434d52f3c135d6c15db1fdc1cfd9b999c0bb..1b725841616b0e5f74243822074141b99ceb4b5e 100644 (file)
@@ -49,7 +49,7 @@ live migration safe.
 The information that follows provides recommendations for configuring
 CPU models on x86 hosts. The goals are to maximise performance, while
 protecting guest OS against various CPU hardware flaws, and optionally
-enabling live migration between hosts with hetergeneous CPU models.
+enabling live migration between hosts with heterogeneous CPU models.
 
 @menu
 * preferred_cpu_models_intel_x86::       Preferred CPU models for Intel x86 hosts
@@ -287,7 +287,7 @@ Must be explicitly turned on for all AMD CPU models.
 This provides higher performance than virt-ssbd so should be
 exposed to guests whenever available in the host. virt-ssbd
 should none the less also be exposed for maximum guest
-compatability as some kernels only know about virt-ssbd.
+compatibility as some kernels only know about virt-ssbd.
 
 
 @item @code{amd-no-ssb}
@@ -296,7 +296,7 @@ Recommended to indicate the host is not vulnerable CVE-2018-3639
 
 Not included by default in any AMD CPU model.
 
-Future hardware genarations of CPU will not be vulnerable to
+Future hardware generations of CPU will not be vulnerable to
 CVE-2018-3639, and thus the guest should be told not to enable
 its mitigations, by exposing amd-no-ssb. This is mutually
 exclusive with virt-ssbd and amd-ssbd.
@@ -451,7 +451,7 @@ MIPS64 Processor (Release 6, 2014)
 
 @item @code{Loongson-2F}
 
-MIPS64 Processor (Longsoon 2, 2008)
+MIPS64 Processor (Loongson 2, 2008)
 
 
 @item @code{Loongson-2E}
index e6f990261751249a3c602a18c8a41fedb4675a7e..a86e992c84538609876baf26291fb5c3edbd4c9d 100644 (file)
@@ -30,7 +30,7 @@ of the significantly lower latency and higher throughput over TCP/IP. This is
 because the RDMA I/O architecture reduces the number of interrupts and
 data copies by bypassing the host networking stack. In particular, a TCP-based
 migration, under certain types of memory-bound workloads, may take a more
-unpredicatable amount of time to complete the migration if the amount of
+unpredictable amount of time to complete the migration if the amount of
 memory tracked during each live migration iteration round cannot keep pace
 with the rate of dirty memory produced by the workload.
 
@@ -408,7 +408,7 @@ socket is broken during a non-RDMA based migration.
 TODO:
 =====
 1. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
-   are not compatible with infinband memory pinning and will result in
+   are not compatible with infiniband memory pinning and will result in
    an aborted migration (but with the source VM left unaffected).
 2. Use of the recent /proc/<pid>/pagemap would likely speed up
    the use of KSM and ballooning while using RDMA.
index 3497585f5a39b2592230a8a7896eab1f6eeff2f8..ee6aee9861e7a6823f762b51bc7b2dee4d49591e 100644 (file)
@@ -290,7 +290,7 @@ E.g., '-serial stdio' in record mode, and '-serial null' in replay mode.
 Replay log format
 -----------------
 
-Record/replay log consits of the header and the sequence of execution
+Record/replay log consists of the header and the sequence of execution
 events. The header includes 4-byte replay version id and 8-byte reserved
 field. Version is updated every time replay log format changes to prevent
 using replay log created by another build of qemu.
index 8cd060a01e109d81d8232c2008cbda4c32a509ec..b1eb2deeaf2fe771800a80e6fe53e71a65e75749 100644 (file)
@@ -671,7 +671,7 @@ These are the steps:
       -> IOMMU Hardware Support
          select S390 AP IOMMU Support
       -> VFIO Non-Privileged userspace driver framework
-         -> Mediated device driver frramework
+         -> Mediated device driver framework
             -> VFIO driver for Mediated devices
    -> I/O subsystem
       -> VFIO support for AP devices