mirror of
https://github.com/projectacrn/acrn-hypervisor.git
synced 2025-06-22 21:47:22 +00:00
doc: fix misspellings in hld docs
can and fix misspellings missed during normal review Tracked-on: #1648 Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
parent
569ababd86
commit
97c8c16f6a
@ -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,
|
As Service OS has full knowledge of these huge pages size,
|
||||||
GPA\ :sup:`SOS` and GPA\ :sup:`UOS`, it works with the hypervisor
|
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
|
.. code-block: none
|
||||||
|
|
||||||
|
@ -53,7 +53,7 @@ Virtio introduction
|
|||||||
Virtio is an abstraction layer over devices in a para-virtualized
|
Virtio is an abstraction layer over devices in a para-virtualized
|
||||||
hypervisor. Virtio was developed by Rusty Russell when he worked at IBM
|
hypervisor. Virtio was developed by Rusty Russell when he worked at IBM
|
||||||
research to support his lguest hypervisor in 2007, and it quickly became
|
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
|
Virtio is very popular for virtual I/O devices because is provides a
|
||||||
straightforward, efficient, standard, and extensible mechanism, and
|
straightforward, efficient, standard, and extensible mechanism, and
|
||||||
|
@ -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
|
direction. It will finally complete this MMIO request emulation
|
||||||
by:
|
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
|
b. getting req.val from req.addr for read operation
|
||||||
|
|
||||||
5. If the access direction is read, then do *emulate_instruction* to
|
5. If the access direction is read, then do *emulate_instruction* to
|
||||||
|
@ -1,6 +1,6 @@
|
|||||||
.. _hv-device-passthrough:
|
.. _hv-device-passthrough:
|
||||||
|
|
||||||
Device PassThrough
|
Device Passthrough
|
||||||
##################
|
##################
|
||||||
|
|
||||||
A critical part of virtualization is virtualizing devices: exposing all
|
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.
|
model.
|
||||||
|
|
||||||
- When configuration emulation is in the hypervisor, the interception of
|
- 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
|
tricky and unclean. Therefore the final solution is to reuse the
|
||||||
PCI emulation infrastructure of SOS device model. The hypervisor
|
PCI emulation infrastructure of SOS device model. The hypervisor
|
||||||
routes the UOS 0xCF8/CFC access to device model, and keeps blind to the
|
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
|
Initialization of remapping of virtual IOAPIC interrupts for SOS
|
||||||
|
|
||||||
:numref:`init-remapping` above illustrates how remapping of (virtual) IOAPIC
|
: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
|
unmask an interrupt in (virtual) IOAPIC by writing to the Redirection
|
||||||
Table Entry (or RTE). The hypervisor then invokes the IOAPIC emulation
|
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
|
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:
|
the following steps:
|
||||||
|
|
||||||
- UOS gets a virtual interrupt
|
- 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.
|
will be injected.
|
||||||
- Hypervisor will handle the interrupt and translate the vector
|
- Hypervisor will handle the interrupt and translate the vector
|
||||||
according to ptdev_remapping_info.
|
according to ptdev_remapping_info.
|
||||||
|
@ -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
|
exit processing flow will call dispatch_interrupt() to dispatch and
|
||||||
handle the interrupt.
|
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
|
:numref:`phy-interrupt-processing`, ACRN hypervisor will jump to
|
||||||
dispatch_interrupt. This function gets the vector of the generated
|
dispatch_interrupt. This function gets the vector of the generated
|
||||||
interrupt from the context, gets IRQ number from vector_to_irq[], and
|
interrupt from the context, gets IRQ number from vector_to_irq[], and
|
||||||
|
@ -148,12 +148,12 @@ Secure World. Secure world can access Normal World's memory, but Normal
|
|||||||
world cannot access Secure World's memory.
|
world cannot access Secure World's memory.
|
||||||
|
|
||||||
VM0 domain
|
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.
|
Service OS.
|
||||||
|
|
||||||
IOMMU uses the EPT table of Normal world of VM0 as the address
|
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
|
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
|
and Secure worlds if any. So the devices in VM0 domain can’t access the
|
||||||
memory belong to hypervisor or secure worlds.
|
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
|
OS, which changes the address translation table from EPT of VM0 to EPT
|
||||||
of User OS for the device.
|
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
|
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
|
back to VM0 domain, which changes the address translation table from EPT
|
||||||
of User OS to EPT of VM0 for the device.
|
of User OS to EPT of VM0 for the device.
|
||||||
|
@ -486,7 +486,7 @@ optional):
|
|||||||
|
|
||||||
-s 4,virtio-net,<tap_name>,[mac=<XX:XX:XX:XX:XX:XX>]
|
-s 4,virtio-net,<tap_name>,[mac=<XX:XX:XX:XX:XX:XX>]
|
||||||
|
|
||||||
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:
|
is the virtual NIC created by acrn-dm:
|
||||||
|
|
||||||
.. code-block:: none
|
.. 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,
|
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
|
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
|
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
|
necessary to separate the data plane from the control plane. We can use
|
||||||
vhost for acceleration. For most IoT scenarios, processing in user space
|
vhost for acceleration. For most IoT scenarios, processing in user space
|
||||||
is simple and reasonable.
|
is simple and reasonable.
|
||||||
|
Loading…
Reference in New Issue
Block a user