|
3 | 3 | Hypercall / VHM upcall
|
4 | 4 | ######################
|
5 | 5 |
|
6 |
| -Hypercall/upcall used to request services between Guest VM and hypervisor, |
7 |
| -hypercall is from Guest VM to hypervisor, upcall is from hypervisor to Guest VM. |
8 |
| -Hypervisor currently supports hypercall APIs for VM management, I/O request |
9 |
| -distribution,interrupt injection, PCI assignment, guest memory mapping, |
10 |
| -power management and secure world switch. |
| 6 | +The hypercall/upcall is used to request services between the Guest VM and the hypervisor. |
| 7 | +The hypercall is from the Guest VM to hypervisor, and the upcall is from the hypervisor to the Guest VM. |
| 8 | +The hypervisor currently supports hypercall APIs for VM management, I/O request |
| 9 | +distribution, interrupt injection, PCI assignment, guest memory mapping, |
| 10 | +power management, and secure world switch. |
11 | 11 |
|
12 | 12 | There are some restrictions for hypercall and upcall:
|
13 | 13 |
|
14 |
| -#. Only ring0 hypercalls from the guest VM are handled by the hypervisor, |
15 |
| - otherwise hypervisor will inject GP to Guest VM. |
16 |
| -#. All the hypercalls (except secure world hypercalls) must be called from SOS VM, |
17 |
| - otherwise hypervisor will inject UD to Guest VM. |
| 14 | +#. Only ring 0 hypercalls from the guest VM are handled by the hypervisor; |
| 15 | + otherwise, the hypervisor will inject GP to the Guest VM. |
| 16 | +#. All the hypercalls (except secure world hypercalls) must be called from the Service VM; |
| 17 | + otherwise, the hypervisor will inject UD to the Guest VM. |
18 | 18 | see :ref:`secure-hypervisor-interface` for a detailed description.
|
19 |
| -#. Hypervisor needs to protect the critical resources such as global VM and VCPU structures |
| 19 | +#. The hypervisor needs to protect the critical resources such as global VM and VCPU structures |
20 | 20 | for VM and VCPU management hypercalls.
|
21 |
| -#. Upcall is only used for SOS VM. |
| 21 | +#. Upcall is only used for the Service VM. |
22 | 22 |
|
23 | 23 |
|
24 |
| -HV and Service OS (SOS) both use the same vector(0xF3) reserved as x86 platform |
25 |
| -IPI vector for HV notification to SOS. This upcall is necessary whenever |
26 |
| -there is device emulation requirement to SOS. The upcall vector(0xF3) is |
27 |
| -injected to SOS vCPU0.SOS will register the irq handler for vector(0xF3) and notify the I/O emulation |
28 |
| -module in SOS once the irq is triggered. |
29 |
| -The detailed upcall process see :ref:`ipi-management` |
| 24 | +HV and Service VM both use the same vector (0xF3) reserved as x86 platform |
| 25 | +IPI vector for HV notification to the Service VM. This upcall is necessary whenever |
| 26 | +there is device emulation requirement to the Service VM. The upcall vector (0xF3) is |
| 27 | +injected to Service VM vCPU0. The Service VM will register the irq handler for vector (0xF3) and notify the I/O emulation |
| 28 | +module in the Service VM once the irq is triggered. |
| 29 | +View the detailed upcall process at :ref:`ipi-management` |
30 | 30 |
|
31 | 31 | Hypercall APIs reference:
|
32 | 32 | *************************
|
33 | 33 |
|
34 |
| -:ref:`hypercall_apis` for SOS |
| 34 | +:ref:`hypercall_apis` for the Service VM |
35 | 35 |
|
36 | 36 | :ref:`trusty-hypercalls` for Trusty
|
37 | 37 |
|
|
0 commit comments