The interrupt window includes: * sti * mov ss On real x86 processors, after certain instructions(mov ss/pop ss/sti), an interrupt is guaranteed not to be delivered for exactly one instruction, not just an indefinite amount of time. For mov ss/pop ss, this is architecturally defined so that loading a new stack segment plus stack pointer together can be done atomically (without an interrupt handler running in the middle and using a half-initialized stack address). For sti, this delay allows the kernel to do sti ret, without an interrupt handler running before we return from the current routine. However, the virtualization instructions allow the hypervisor to inject interrupts. Therefore, it's the hypervisor/VMM's responsbility to not to deliver an interrupt on an unexpected places on the guest. This test uses port IO to trigger VMEXIT before and after mov ss or sti, and tests the interruptibility under different occasions. It also tests when the interrupt will be delivered. TEST=./tools/dev_container cargo nextest run --workspace --profile=default -E 'package(hypervisor) & binary(hypervisor_virtualization) & test(interruptible)' --retries 0 --no-capture BUG=b:334055761 Change-Id: Ib800c5e8054b4bcc4b20899d2cea1b113081c0e7 Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5568137 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Kaiyi Li <kaiyili@google.com> Reviewed-by: Judson Powers <judsonp@google.com> |
||
|---|---|---|
| .. | ||
| hypervisor_test_macro | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
Hypervisor Support
Multiple hypervisor backends are supported. See Advanced Usage for overriding the default backend.
Hypervisors added to crosvm must meet the following requirements:
- Hypervisor code must be buildable in crosvm upstream.
- Within reason, crosvm maintainers will ensure the hypervisor's code continues to build.
- Hypervisors are not required to be tested upstream.
- We can't require testing upstream because some hypervisors require specialized hardware.
- When not tested upstream, the hypervisor's maintainers are expected to test it downstream. If a change to crosvm breaks something downstream, then the hypervisor's maintainers are expected to supply the fix and can't expect a revert of the culprit change to be accepted upstream.
KVM
- Platforms: Linux
- Tested upstream: yes
KVM is crosvm's preferred hypervisor for Linux.
WHPX
- Platforms: Windows
- Tested upstream: no
- Contacts: vnagarnaik@google.com
HAXM
- Platforms: Windows
- Tested upstream: no
- Contacts: vnagarnaik@google.com
Android Specific
The hypervisors in this section are used as backends of the Android Virtualization Framework.
Geniezone
- Platforms: Linux, aarch64 only
- Tested upstream: no
- Contacts: fmayle@google.com, smoreland@google.com
Gunyah
- Platforms: Linux, aarch64 only
- Tested upstream: no
- Contacts: quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, fmayle@google.com, smoreland@google.com