From: Wei Yang <richardw.yang@linux.intel.com>
To: Like Xu <like.xu@linux.intel.com>
Cc: qemu-trivial@nongnu.org, Laurent Vivier <laurent@vivier.eu>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] doc: update .gitignore and fix typos for docs in tree
Date: Wed, 20 Feb 2019 11:00:25 +0800 [thread overview]
Message-ID: <20190220030025.GA25796@richard> (raw)
In-Reply-To: <1550652953-24393-1-git-send-email-like.xu@linux.intel.com>
On Wed, Feb 20, 2019 at 04:55:53PM +0800, Like Xu wrote:
>Signed-off-by: Like Xu <like.xu@linux.intel.com>
>---
> .gitignore | 1 +
> docs/COLO-FT.txt | 2 +-
> docs/amd-memory-encryption.txt | 2 +-
> docs/can.txt | 2 +-
> docs/colo-proxy.txt | 6 +++---
> docs/cpu-hotplug.rst | 2 +-
> docs/qcow2-cache.txt | 2 +-
> docs/qemu-block-drivers.texi | 2 +-
> docs/qemu-cpu-models.texi | 4 ++--
> docs/rdma.txt | 2 +-
> docs/replay.txt | 2 +-
> docs/usb-storage.txt | 2 +-
> docs/vfio-ap.txt | 2 +-
> 13 files changed, 16 insertions(+), 15 deletions(-)
>
>diff --git a/.gitignore b/.gitignore
>index b66b772..6cb0016 100644
>--- a/.gitignore
>+++ b/.gitignore
>@@ -90,6 +90,7 @@
> *.d
> !/scripts/qemu-guest-agent/fsfreeze-hook.d
> *.o
>+*.patch
> .sdk
> *.gcda
> *.gcno
suggest to split this into a standalone one.
>diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
>index e2686bb..ad24680 100644
>--- a/docs/COLO-FT.txt
>+++ b/docs/COLO-FT.txt
>@@ -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.
>
>diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
>index f483795..43bf3ee 100644
>--- a/docs/amd-memory-encryption.txt
>+++ b/docs/amd-memory-encryption.txt
>@@ -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:
>diff --git a/docs/can.txt b/docs/can.txt
>index 7ba23b2..9fa6ed5 100644
>--- a/docs/can.txt
>+++ b/docs/can.txt
>@@ -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
>diff --git a/docs/colo-proxy.txt b/docs/colo-proxy.txt
>index 1f8e4b4..7074da7 100644
>--- a/docs/colo-proxy.txt
>+++ b/docs/colo-proxy.txt
>@@ -41,7 +41,7 @@ Below is a COLO proxy ascii figure:
> | | +------------------------------------------------------+ | | | |
> |netfilter| | | | | | netfilter | | |
> | +----------+ +----------------------------+ | | | +-----------------------------------------------------------+ |
>-| | | | | | out | | | | | | filter excute order | |
>+| | | | | | out | | | | | | filter execute order | |
^
remove one space here?
> | | | | +-----------------------------+ | | | | | | +-------------------> | |
> | | | | | | | | | | | | | | 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 | | | | | | |
the same as above
> | | | +----------------> | | | +--------------------------------------------------------+ |
> | +-----------------------------------------+ | | |
> | | | | | |
>@@ -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.
>diff --git a/docs/cpu-hotplug.rst b/docs/cpu-hotplug.rst
>index 1c268e0..cfeb79f 100644
>--- a/docs/cpu-hotplug.rst
>+++ b/docs/cpu-hotplug.rst
>@@ -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.
>diff --git a/docs/qcow2-cache.txt b/docs/qcow2-cache.txt
>index c459bf5..c1e7751 100644
>--- a/docs/qcow2-cache.txt
>+++ b/docs/qcow2-cache.txt
>@@ -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.
>diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi
>index 38e9f34..1b1ac19 100644
>--- a/docs/qemu-block-drivers.texi
>+++ b/docs/qemu-block-drivers.texi
>@@ -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 accessing 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
>diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi
>index 475d434..4354fe8 100644
>--- a/docs/qemu-cpu-models.texi
>+++ b/docs/qemu-cpu-models.texi
>@@ -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.
>diff --git a/docs/rdma.txt b/docs/rdma.txt
>index e6f9902..1e6f23e 100644
>--- a/docs/rdma.txt
>+++ b/docs/rdma.txt
>@@ -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.
>
>diff --git a/docs/replay.txt b/docs/replay.txt
>index 3497585..ee6aee9 100644
>--- a/docs/replay.txt
>+++ b/docs/replay.txt
>@@ -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.
>diff --git a/docs/usb-storage.txt b/docs/usb-storage.txt
>index 551af6f..3df6d05 100644
>--- a/docs/usb-storage.txt
>+++ b/docs/usb-storage.txt
>@@ -16,7 +16,7 @@ too):
>
>
> Number two is the newer usb attached scsi transport. This one doesn't
>-automagically create a scsi disk, so you have to explicitly attach one
>+automatically create a scsi disk, so you have to explicitly attach one
> manually. Multiple logical units are supported. Here is an example
> with tree logical units:
>
>diff --git a/docs/vfio-ap.txt b/docs/vfio-ap.txt
>index 1233968..30f3c66 100644
>--- a/docs/vfio-ap.txt
>+++ b/docs/vfio-ap.txt
>@@ -624,7 +624,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
others looks good to me.
>--
>1.8.3.1
>
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2019-02-20 3:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 8:55 [Qemu-devel] [PATCH] doc: update .gitignore and fix typos for docs in tree Like Xu
2019-02-20 3:00 ` Wei Yang [this message]
2019-02-20 3:09 ` Eric Blake
2019-02-20 5:39 ` Like Xu
2019-02-20 13:45 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190220030025.GA25796@richard \
--to=richardw.yang@linux.intel.com \
--cc=laurent@vivier.eu \
--cc=like.xu@linux.intel.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).