2018-10-31 02:02:29 +08:00
|
|
|
.. _hv-hypercall:
|
|
|
|
|
|
2021-07-02 11:47:31 +08:00
|
|
|
Hypercall / HSM Upcall
|
2018-10-31 02:02:29 +08:00
|
|
|
######################
|
|
|
|
|
|
2022-03-19 02:46:56 +08:00
|
|
|
The hypercall/upcall is used to request services between the guest VM and the
|
|
|
|
|
hypervisor. The hypercall is from the guest VM to the hypervisor, and the upcall
|
|
|
|
|
is from the hypervisor to the guest VM. The hypervisor supports
|
|
|
|
|
hypercall APIs for VM management, I/O request distribution, interrupt injection,
|
|
|
|
|
PCI assignment, guest memory mapping, power management, and secure world switch.
|
2018-10-31 02:02:29 +08:00
|
|
|
|
2019-10-15 12:08:12 +08:00
|
|
|
There are some restrictions for hypercall and upcall:
|
|
|
|
|
|
2022-03-19 02:46:56 +08:00
|
|
|
#. Only specific VMs (the Service VM and the VM with Trusty enabled)
|
|
|
|
|
can invoke hypercalls. A VM that cannot invoke hypercalls gets ``#UD``
|
|
|
|
|
(invalid opcode exception).
|
2019-11-09 06:28:46 +08:00
|
|
|
#. Only ring 0 hypercalls from the guest VM are handled by the hypervisor;
|
2022-03-19 02:46:56 +08:00
|
|
|
otherwise, the hypervisor injects ``#GP(0)`` (generation protection
|
|
|
|
|
exception with error code ``0``) to the guest VM.
|
|
|
|
|
#. Each VM is permitted to invoke a certain subset of hypercalls. A VM
|
|
|
|
|
with Trusty enabled is allowed to invoke Trusty hypercalls, and the Service
|
hv: hypercalls: refactor permission-checking and dispatching logic
The current permission-checking and dispatching mechanism of hypercalls is
not unified because:
1. Some hypercalls require the exact vCPU initiating the call, while the
others only need to know the VM.
2. Different hypercalls have different permission requirements: the
trusty-related ones are enabled by a guest flag, while the others
require the initiating VM to be the Service OS.
Without a unified logic it could be hard to scale when more kinds of
hypercalls are added later.
The objectives of this patch are as follows.
1. All hypercalls have the same prototype and are dispatched by a unified
logic.
2. Permissions are checked by a unified logic without consulting the
hypercall ID.
To achieve the first objective, this patch modifies the type of the first
parameter of hcall_* functions (which are the callbacks implementing the
hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The
doxygen-style documentations are updated accordingly.
To achieve the second objective, this patch adds to `struct hc_dispatch` a
`permission_flags` field which specifies the guest flags that must ALL be
set for a VM to be able to invoke the hypercall. The default value (which
is 0UL) indicates that this hypercall is for SOS only. Currently only the
`permission_flag` of trusty-related hypercalls have the non-zero value
GUEST_FLAG_SECURE_WORLD_ENABLED.
With `permission_flag`, the permission checking logic of hypercalls is
unified as follows.
1. General checks
i. If the VM is neither SOS nor having any guest flag that allows
certain hypercalls, it gets #UD upon executing the `vmcall`
instruction.
ii. If the VM is allowed to execute the `vmcall` instruction, but
attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0).
2. Hypercall-specific checks
i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the
initiating VM must be SOS and the specified target VM cannot be a
pre-launched VM. Otherwise the hypercall returns -EINVAL without
further actions.
ii. If the hypercall requires certain guest flags, the initiating VM
must have all the required flags. Otherwise the hypercall returns
-EINVAL without further actions.
iii. A hypercall with an unknown hypercall ID makes the hypercall
returns -EINVAL without further actions.
The logic above is different from the current implementation in the
following aspects.
1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts
to execute `vmcall` in ring 1, 2 or 3.
2. A pre-launched VM now gets #UD (rather than the return value -EPERM)
when it attempts to execute a trusty hypercall in ring 0.
3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it
attempts to invoke a trusty hypercall.
4. A post-launched VM with trusty support now gets the return value
-EINVAL (rather than #UD) when it attempts to invoke a non-trusty
hypercall or an invalid hypercall.
v1 -> v2:
- Update documentation that describe hypercall behavior.
- Fix Doxygen warnings
Tracked-On: #5924
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-05-07 13:17:22 +08:00
|
|
|
VM is allowed to invoke the other hypercalls. A VM that invokes an
|
2022-03-19 02:46:56 +08:00
|
|
|
unpermitted hypercall gets the return value ``-EINVAL``.
|
|
|
|
|
See :ref:`secure-hypervisor-interface` for a detailed description.
|
|
|
|
|
#. The hypervisor needs to protect the critical resources such as global VM and
|
|
|
|
|
vCPU structures for VM and vCPU management hypercalls.
|
2019-11-09 06:28:46 +08:00
|
|
|
#. Upcall is only used for the Service VM.
|
2018-10-31 02:02:29 +08:00
|
|
|
|
2019-10-15 12:08:12 +08:00
|
|
|
|
2022-03-19 02:46:56 +08:00
|
|
|
The hypervisor and Service VM both use the same vector (0xF3), which is reserved
|
|
|
|
|
as the x86 platform IPI vector for hypervisor notification to the Service VM.
|
|
|
|
|
This upcall is necessary whenever there is a device emulation requirement to the
|
|
|
|
|
Service VM. The upcall vector (0xF3) is injected to Service VM vCPU0. The
|
|
|
|
|
Service VM registers the IRQ handler for vector (0xF3) and notifies the I/O
|
|
|
|
|
emulation module in the Service VM once the IRQ is triggered. View the detailed
|
|
|
|
|
upcall process at :ref:`ipi-management`.
|
2019-10-15 12:08:12 +08:00
|
|
|
|
2022-03-19 02:46:56 +08:00
|
|
|
Hypercall APIs Reference
|
|
|
|
|
************************
|
2019-10-15 12:08:12 +08:00
|
|
|
|
2019-11-09 06:28:46 +08:00
|
|
|
:ref:`hypercall_apis` for the Service VM
|
2019-10-15 12:08:12 +08:00
|
|
|
|
|
|
|
|
:ref:`trusty-hypercalls` for Trusty
|
2018-10-31 02:02:29 +08:00
|
|
|
|
|
|
|
|
|