github/acrn-hypervisor
1
0
Fork 0
mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2025-06-19 20:22:46 +00:00
Code Issues Projects Releases Wiki Activity

Doc: Final edits to the CPU Virt doc

Browse Source 
Signed-off-by: Deb Taylor <deb.taylor@intel.com>
This commit is contained in:
Deb Taylor 2019-11-08 17:11:31 -05:00 committed by deb-intel
parent 8ccb21533e
commit a1dca993e8
1 changed files with 25 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
doc/developer-guides/hld/hv-cpu-virt.rst
View File

@ -23,7 +23,7 @@ Based on Intel VT-x virtualization technology, ACRN emulates a virtual CPU
information.) information.)
- **core sharing** (to be added): two or more vCPUs are sharing one - **core sharing** (to be added): two or more vCPUs are sharing one
physical CPU (pCPU), more complicated context switch is needed physical CPU (pCPU); a more complicated context switch is needed
between different vCPUs' switching, and provides flexible computing between different vCPUs' switching, and provides flexible computing
resources sharing for low performance demand vCPU tasks. resources sharing for low performance demand vCPU tasks.
(See `Flexible CPU Sharing`_ for more information.) (See `Flexible CPU Sharing`_ for more information.)
@ -69,16 +69,16 @@ scheduler" as the schedule policy for corresponding physical CPU.
``vcpu_affinity`` in ``vm config`` help to decide which physical CPU two ``vcpu_affinity`` in ``vm config`` help to decide which physical CPU two
or more VCPUs from different VMs are sharing. or more VCPUs from different VMs are sharing.
CPU management in SOS under static CPU partitioning CPU management in the Service VM under static CPU partitioning
=================================================== ==============================================================
With ACRN, all ACPI table entries are pass-thru to the SOS, including With ACRN, all ACPI table entries are pass-thru to the Service VM, including
the Multiple Interrupt Controller Table (MADT). The SOS sees all the Multiple Interrupt Controller Table (MADT). The Service VM sees all
physical CPUs by parsing the MADT when the SOS kernel boots. All physical CPUs by parsing the MADT when the Service VM kernel boots. All
physical CPUs are initially assigned to the SOS by creating the same physical CPUs are initially assigned to the Service VM by creating the same
number of virtual CPUs. number of virtual CPUs.
When the SOS boot is finished, it releases the physical CPUs intended When the Service VM boot is finished, it releases the physical CPUs intended
for UOS use. for UOS use.
Here is an example flow of CPU allocation on a multi-core platform. Here is an example flow of CPU allocation on a multi-core platform.
@ -90,13 +90,13 @@ Here is an example flow of CPU allocation on a multi-core platform.
CPU allocation on a multi-core platform CPU allocation on a multi-core platform
CPU management in SOS under flexing CPU sharing CPU management in the Service VM under flexing CPU sharing
=============================================== ==========================================================
As all SOS CPUs could share with different UOSs, ACRN can still pass-thru As all Service VM CPUs could share with different UOSs, ACRN can still pass-thru
MADT to Service VM, and the SOS is still able to see all physcial CPUs. MADT to Service VM, and the Service VM is still able to see all physcial CPUs.
But as under CPU sharing, SOS does not need offline/release the physical But as under CPU sharing, the Service VM does not need offline/release the physical
CPUs intended for UOS use. CPUs intended for UOS use.
CPU management in UOS CPU management in UOS
@ -567,7 +567,7 @@ For a guest vCPU's state initialization:
- If it's BSP, the guest state configuration is done in SW load, - If it's BSP, the guest state configuration is done in SW load,
which could be initialized by different objects: which could be initialized by different objects:
- SOS BSP: hypervisor will do context initialization in different - The Service VM BSP: hypervisor will do context initialization in different
SW load based on different boot mode SW load based on different boot mode
@ -882,8 +882,8 @@ pass-through directly:
* - MSR_IA32_BIOS_UPDT_TRIG * - MSR_IA32_BIOS_UPDT_TRIG
- BIOS update trigger - BIOS update trigger
- work for update microcode from SOS, the signature ID read is from - work for update microcode from the Service VM, the signature ID read is from
physical MSR, and a BIOS update trigger from SOS will trigger a physical MSR, and a BIOS update trigger from the Service VM will trigger a
physical microcode update. physical microcode update.
* - MSR_IA32_BIOS_SIGN_ID * - MSR_IA32_BIOS_SIGN_ID
@ -1088,13 +1088,13 @@ ACRN always enables I/O bitmap in *VMX_PROC_VM_EXEC_CONTROLS* and EPT
in *VMX_PROC_VM_EXEC_CONTROLS2*. Based on them, in *VMX_PROC_VM_EXEC_CONTROLS2*. Based on them,
*pio_instr_vmexit_handler* and *ept_violation_vmexit_handler* are *pio_instr_vmexit_handler* and *ept_violation_vmexit_handler* are
used for IO/MMIO emulation for a emulated device. The emulated device used for IO/MMIO emulation for a emulated device. The emulated device
could locate in hypervisor or DM in SOS. Please refer to the "I/O could locate in hypervisor or DM in the Service VM. Please refer to the "I/O
Emulation" section for more details. Emulation" section for more details.
For an emulated device done in the hypervisor, ACRN provide some basic For an emulated device done in the hypervisor, ACRN provide some basic
APIs to register its IO/MMIO range: APIs to register its IO/MMIO range:
- For SOS, the default I/O bitmap are all set to 0, which means SOS will pass - For the Service VM, the default I/O bitmap are all set to 0, which means the Service VM will pass
through all I/O port access by default. Adding an I/O handler through all I/O port access by default. Adding an I/O handler
for a hypervisor emulated device needs to first set its corresponding for a hypervisor emulated device needs to first set its corresponding
I/O bitmap to 1. I/O bitmap to 1.
@ -1103,11 +1103,11 @@ APIs to register its IO/MMIO range:
all I/O port access by default. Adding an I/O handler for a all I/O port access by default. Adding an I/O handler for a
hypervisor emulated device does not need change its I/O bitmap. hypervisor emulated device does not need change its I/O bitmap.
If the trapped I/O port access does not fall into a hypervisor If the trapped I/O port access does not fall into a hypervisor
emulated device, it will create an I/O request and pass it to SOS emulated device, it will create an I/O request and pass it to the Service VM
DM. DM.
- For SOS, EPT maps all range of memory to the SOS except for ACRN hypervisor - For the Service VM, EPT maps all range of memory to the Service VM except for ACRN hypervisor
area. This means SOS will pass through all MMIO access by area. This means the Service VM will pass through all MMIO access by
default. Adding a MMIO handler for a hypervisor emulated default. Adding a MMIO handler for a hypervisor emulated
device needs to first remove its MMIO range from EPT mapping. device needs to first remove its MMIO range from EPT mapping.
@ -1115,7 +1115,7 @@ APIs to register its IO/MMIO range:
trap all MMIO access by default. Adding a MMIO handler for a trap all MMIO access by default. Adding a MMIO handler for a
hypervisor emulated device does not need to change its EPT mapping. hypervisor emulated device does not need to change its EPT mapping.
If the trapped MMIO access does not fall into a hypervisor If the trapped MMIO access does not fall into a hypervisor
emulated device, it will create an I/O request and pass it to SOS emulated device, it will create an I/O request and pass it to the Service VM
DM. DM.
.. list-table:: .. list-table::
@ -1207,11 +1207,11 @@ ART Virtualization
The invariant TSC is based on the invariant timekeeping hardware (called The invariant TSC is based on the invariant timekeeping hardware (called
Always Running Timer or ART), that runs at the core crystal clock frequency. Always Running Timer or ART), that runs at the core crystal clock frequency.
The ratio defined by CPUID leaf 15H express the frequency relationship The ratio defined by the CPUID leaf 15H expresses the frequency relationship
between the ART hardware and TSC. between the ART hardware and the TSC.
If CPUID.15H.EBX[31:0] != 0 and CPUID.80000007H:EDX[InvariantTSC] = 1, the If CPUID.15H.EBX[31:0] != 0 and CPUID.80000007H:EDX[InvariantTSC] = 1, the
following linearity relationship holds between TSC and the ART hardware: following linearity relationship holds between the TSC and the ART hardware:
``TSC_Value = (ART_Value * CPUID.15H:EBX[31:0]) / CPUID.15H:EAX[31:0] + K`` ``TSC_Value = (ART_Value * CPUID.15H:EBX[31:0]) / CPUID.15H:EAX[31:0] + K``