diff --git a/doc/developer-guides/hld/hld-overview.rst b/doc/developer-guides/hld/hld-overview.rst index 88fb05d0a..a2d98df21 100644 --- a/doc/developer-guides/hld/hld-overview.rst +++ b/doc/developer-guides/hld/hld-overview.rst @@ -356,7 +356,7 @@ from different huge pages in Service OS as shown in As Service OS has full knowledge of these huge pages size, GPA\ :sup:`SOS` and GPA\ :sup:`UOS`, it works with the hypervisor -to complete UOS's hostr-to-guest mapping using this pseudo code: +to complete UOS's host-to-guest mapping using this pseudo code: .. code-block: none diff --git a/doc/developer-guides/hld/hld-virtio-devices.rst b/doc/developer-guides/hld/hld-virtio-devices.rst index 5bf97766f..0d8da4194 100644 --- a/doc/developer-guides/hld/hld-virtio-devices.rst +++ b/doc/developer-guides/hld/hld-virtio-devices.rst @@ -53,7 +53,7 @@ Virtio introduction Virtio is an abstraction layer over devices in a para-virtualized hypervisor. Virtio was developed by Rusty Russell when he worked at IBM research to support his lguest hypervisor in 2007, and it quickly became -the de-facto standard for KVM's para-virtualized I/O devices. +the de facto standard for KVM's para-virtualized I/O devices. Virtio is very popular for virtual I/O devices because is provides a straightforward, efficient, standard, and extensible mechanism, and diff --git a/doc/developer-guides/hld/hv-cpu-virt.rst b/doc/developer-guides/hld/hv-cpu-virt.rst index c6be41871..88161cecf 100644 --- a/doc/developer-guides/hld/hv-cpu-virt.rst +++ b/doc/developer-guides/hld/hv-cpu-virt.rst @@ -1251,7 +1251,7 @@ In the handlers for EPT violation or APIC access VM exit, ACRN will: direction. It will finally complete this MMIO request emulation by: - a. puting req.val to req.addr for write operation + a. putting req.val to req.addr for write operation b. getting req.val from req.addr for read operation 5. If the access direction is read, then do *emulate_instruction* to diff --git a/doc/developer-guides/hld/hv-dev-passthrough.rst b/doc/developer-guides/hld/hv-dev-passthrough.rst index 35fc79f79..0de9f3a25 100644 --- a/doc/developer-guides/hld/hv-dev-passthrough.rst +++ b/doc/developer-guides/hld/hv-dev-passthrough.rst @@ -1,6 +1,6 @@ .. _hv-device-passthrough: -Device PassThrough +Device Passthrough ################## A critical part of virtualization is virtualizing devices: exposing all @@ -118,7 +118,7 @@ PCI device through two paths: implemented in hypervisor or in SOS device model. - When configuration emulation is in the hypervisor, the interception of - 0xCF8/CFC port and emulatation of PCI configuration space access are + 0xCF8/CFC port and emulation of PCI configuration space access are tricky and unclean. Therefore the final solution is to reuse the PCI emulation infrastructure of SOS device model. The hypervisor routes the UOS 0xCF8/CFC access to device model, and keeps blind to the @@ -160,7 +160,7 @@ done on-demand rather than on hypervisor initialization. Initialization of remapping of virtual IOAPIC interrupts for SOS :numref:`init-remapping` above illustrates how remapping of (virtual) IOAPIC -interrupts are remappied for SOS. VM exit occurs whenever SOS tries to +interrupts are remapped for SOS. VM exit occurs whenever SOS tries to unmask an interrupt in (virtual) IOAPIC by writing to the Redirection Table Entry (or RTE). The hypervisor then invokes the IOAPIC emulation handler (refer to :ref:`hld-io-emulation` for details on I/O emulation) which @@ -183,7 +183,7 @@ When the UOS needs to access the physical device by passthrough, it uses the following steps: - UOS gets a virtual interrupt -- VM exit happens and the trapped vCPU is the target where the interrup +- VM exit happens and the trapped vCPU is the target where the interrupt will be injected. - Hypervisor will handle the interrupt and translate the vector according to ptdev_remapping_info. diff --git a/doc/developer-guides/hld/hv-interrupt.rst b/doc/developer-guides/hld/hv-interrupt.rst index 0a8c41a1a..d3091a3aa 100644 --- a/doc/developer-guides/hld/hv-interrupt.rst +++ b/doc/developer-guides/hld/hv-interrupt.rst @@ -308,7 +308,7 @@ CPU may be running under either VMX root mode or non-root mode. exit processing flow will call dispatch_interrupt() to dispatch and handle the interrupt. -After an interrupt occures from either path shown in +After an interrupt occurs from either path shown in :numref:`phy-interrupt-processing`, ACRN hypervisor will jump to dispatch_interrupt. This function gets the vector of the generated interrupt from the context, gets IRQ number from vector_to_irq[], and diff --git a/doc/developer-guides/hld/hv-vt-d.rst b/doc/developer-guides/hld/hv-vt-d.rst index cd097df0a..de250afd9 100644 --- a/doc/developer-guides/hld/hv-vt-d.rst +++ b/doc/developer-guides/hld/hv-vt-d.rst @@ -148,12 +148,12 @@ Secure World. Secure world can access Normal World's memory, but Normal world cannot access Secure World's memory. VM0 domain - VM0 domain is created when ithe hypervisor creates VM0 for the + VM0 domain is created when the hypervisor creates VM0 for the Service OS. IOMMU uses the EPT table of Normal world of VM0 as the address translation structures for the devices in VM0 domain. The Normal world’s - EPT table of VM0 doesn’t include the memory resource of ithe hypervisor + EPT table of VM0 doesn’t include the memory resource of the hypervisor and Secure worlds if any. So the devices in VM0 domain can’t access the memory belong to hypervisor or secure worlds. @@ -266,7 +266,7 @@ is remove from VM0 domain and added to the VM domain related to the User OS, which changes the address translation table from EPT of VM0 to EPT of User OS for the device. -To un-assign a device means to un-assign the device from an User OS. The +To unassign a device means to unassign the device from an User OS. The device is remove from the VM domain related to the User OS, then added back to VM0 domain, which changes the address translation table from EPT of User OS to EPT of VM0 for the device. diff --git a/doc/developer-guides/hld/virtio-net.rst b/doc/developer-guides/hld/virtio-net.rst index b1d5ad013..01c5aa8a7 100644 --- a/doc/developer-guides/hld/virtio-net.rst +++ b/doc/developer-guides/hld/virtio-net.rst @@ -486,7 +486,7 @@ optional): -s 4,virtio-net,,[mac=] -When the UOS is lauched, run ``ifconfig`` to check the network. enp0s4r +When the UOS is launched, run ``ifconfig`` to check the network. enp0s4r is the virtual NIC created by acrn-dm: .. code-block:: none @@ -517,7 +517,7 @@ top level architecture to the detailed TX and RX flow. Currently, the control plane and data plane are all processed in ACRN device model, which may bring some overhead. But this is not a bottleneck for 1000Mbit NICs or below. Network bandwidth for virtualization can be very close to -the native bandwidgh. For high speed NIC (e.g. 10Gb or above), it is +the native bandwidth. For high speed NIC (e.g. 10Gb or above), it is necessary to separate the data plane from the control plane. We can use vhost for acceleration. For most IoT scenarios, processing in user space is simple and reasonable.