OpenE2K
/
qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

doc: fix typos for documents in tree 

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>
This commit is contained in:
Like Xu 2019-02-20 13:27:26 +08:00 committed by Laurent Vivier
parent d80cf1eb2e
commit 806be3734c
11 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/COLO-FT.txt
View 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.

2
docs/amd-memory-encryption.txt
View 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:

2
docs/can.txt
View 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

6
docs/colo-proxy.txt
View 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.

2
docs/cpu-hotplug.rst
View 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.

2
docs/qcow2-cache.txt
View 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.

2
docs/qemu-block-drivers.texi
View 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

8
docs/qemu-cpu-models.texi
View 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}

4
docs/rdma.txt
View 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.

2
docs/replay.txt
View 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.

2
docs/vfio-ap.txt
View 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