doc: spelling and grammar fixes

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>

doc/developer-guides/GVT-g-porting.rst

@@ -108,7 +108,7 @@ PVINFO, GTT, DISPLAY, and Execlists, and calls back to the AcrnGT
 module through the :ref:`MPT_interface` ``attach_vgpu``. Then, the
 AcrnGT module sets up an I/O request server and asks to trap the PCI
 configure space of the vGPU (virtual device 0:2:0) via VHM's APIs.
-Finally, the AcrnGT module launches a AcrnGT emulation thread to
+Finally, the AcrnGT module launches an AcrnGT emulation thread to
 listen to I/O trap notifications from HVM and ACRN hypervisor.
 
 vGPU destroy scenario

doc/developer-guides/hld/hld-devicemodel.rst

@@ -129,7 +129,7 @@ Here's an example showing how to run a VM with:
 DM Initialization
 *****************
 
-:numref:`dm-boot-flow` shows the overall flow for the DM boot up:
+:numref:`dm-boot-flow` shows the overall flow for the DM boot:
 
 .. figure:: images/dm-image80.png
    :align: center

doc/developer-guides/hld/hld-emulated-devices.rst

@@ -13,7 +13,7 @@ documented in this section.
 
    usb-virt-hld
    UART virtualization <uart-virt-hld>
-   Watchdoc virtualization <watchdog-hld>
+   Watchdog virtualization <watchdog-hld>
    AHCI virtualization <ahci-hld>
    GVT-g GPU Virtualization <hld-APL_GVT-g>
    System timer virtualization <system-timer-hld>

doc/developer-guides/hld/hv-cpu-virt.rst

@@ -186,7 +186,7 @@ a vCPU with VCPU_PAUSED or VCPU_ZOMBIE state runs in default_idle
 loop. The detail behaviors in vcpu_thread and default_idle threads
 are illustrated in :numref:`hv-vcpu-schedule`:
 
--  The **vcpu_thread** loop will do the loop of handling vm exits,
+-  The **vcpu_thread** loop will do the loop of handling VM exits,
    and pending requests around the VM entry/exit.
    It will also check the reschedule request then schedule out to
    default_idle if necessary. See `vCPU Thread`_ for more details
@@ -251,10 +251,10 @@ The vCPU thread flow is a loop as shown and described below:
 3. VM Enter by calling *start/run_vcpu*, then enter non-root mode to do
    guest execution.
 
-4. VM Exit from *start/run_vcpu* when guest trigger vm exit reason in
+4. VM Exit from *start/run_vcpu* when guest trigger VM exit reason in
    non-root mode.
 
-5. Handle vm exit based on specific reason.
+5. Handle VM exit based on specific reason.
 
 6. Loop back to step 1.
 
@@ -270,16 +270,16 @@ the vCPU is saved and restored using this structure:
 The vCPU handles runtime context saving by three different
 categories:
 
--  Always save/restore during vm exit/entry:
+-  Always save/restore during VM exit/entry:
 
-   -  These registers must be saved every time vm exit, and restored
-      every time vm entry
+   -  These registers must be saved every time VM exit, and restored
+      every time VM entry
    -  Registers include: general purpose registers, CR2, and
       IA32_SPEC_CTRL
    -  Definition in *vcpu->run_context*
    -  Get/Set them through *vcpu_get/set_xxx*
 
--  On-demand cache/update during vm exit/entry:
+-  On-demand cache/update during VM exit/entry:
 
    -  These registers are used frequently. They should be cached from
       VMCS on first time access after a VM exit, and updated to VMCS on
@@ -432,7 +432,7 @@ that will trigger an error message and return without handling:
      - APIC write for APICv
 
 
-Details of each vm exit reason handler are described in other sections.
+Details of each VM exit reason handler are described in other sections.
 
 .. _pending-request-handlers:
 
@@ -849,7 +849,7 @@ ACRN always enables MSR bitmap in *VMX_PROC_VM_EXEC_CONTROLS* VMX
 execution control field. This bitmap marks the MSRs to cause a VM
 exit upon guest access for both read and write. The VM
 exit reason for reading or writing these MSRs is respectively
-*VMX_EXIT_REASON_RDMSR* or *VMX_EXIT_REASON_WRMSR* and the vm exit
+*VMX_EXIT_REASON_RDMSR* or *VMX_EXIT_REASON_WRMSR* and the VM exit
 handler is *rdmsr_vmexit_handler* or *wrmsr_vmexit_handler*.
 
 This table shows the predefined MSRs ACRN will trap for all the guests. For
@@ -1002,7 +1002,7 @@ hypervisor on CR writes.
 
 For ``mov to cr0`` and ``mov to cr4``, ACRN sets
 *cr0_host_mask/cr4_host_mask* into *VMX_CR0_MASK/VMX_CR4_MASK*
-for the bitmask causing vm exit.
+for the bitmask causing VM exit.
 
 As ACRN always enables ``unrestricted guest`` in
 *VMX_PROC_VM_EXEC_CONTROLS2*, *CR0.PE* and *CR0.PG* can be

doc/developer-guides/hld/hv-ioc-virt.rst

@@ -602,7 +602,7 @@ IOC mediator and UART DM.
 The "lpc_port" is "com1" or "com2", IOC mediator needs one unassigned
 lpc port for data transfer between User VM and Service VM.
 
-The "wakeup_reason" is IOC mediator boot up reason, each bit represents
+The "wakeup_reason" is IOC mediator boot reason, each bit represents
 one wakeup reason.
 
 For example, the following commands are used to enable IOC feature, the

doc/developer-guides/hld/hv-vm-management.rst

@@ -54,10 +54,9 @@ management. Please refer to ACRN power management design for more details.
 Post-launched User VMs
 ======================
 
-DM is taking control of post-launched User VMs' state transition after Service VM
-boot up, and it calls VM APIs through hypercalls.
-
-Service VM user level service like Life-Cycle-Service and tool like Acrnd may work
-together with DM to launch or stop a User VM. Please refer to ACRN tool
-introduction for more details.
+DM takes control of post-launched User VMs' state transition after the Service VM
+boots, by calling VM APIs through hypercalls.
 
+Service VM user level service such as Life-Cycle-Service and tools such
+as Acrnd may work together with DM to launch or stop a User VM. Please
+refer to ACRN tool introduction for more details.

doc/developer-guides/trusty.rst

@@ -69,7 +69,7 @@ As shown in the above figure, here are some details about the Trusty boot flow p
    #. Resume to Secure World
 #. Trusty
 
-   a. Booting up
+   a. Booting
    #. Call ``hcall_world_switch`` to switch back to Normal World if boot completed
 #. ACRN (``hcall_world_switch``)