Host freezes / hard lockup several seconds after successful vmi_slat_switch in nested virtualization (switch-view-example.c)

[fengjian]

Description

When running the official switch-view-example.c from LibVMI (using KVM backend from KVM-VMI project) in a nested virtualization environment:

• All LibVMI calls succeed: vmi_slat_create(1), vmi_slat_switch(1), vmi_slat_switch(0), vmi_slat_destroy(1) return VMI_SUCCESS (no error messages printed).
• The program appears to complete normally.
• However, several seconds after the example finishes (typically 3–10 seconds), the entire host (L1) becomes completely unresponsive (hard freeze / lockup). No kernel panic message in dmesg/journalctl, SSH disconnects, no response to keyboard/mouse, requires hard reset.

This is not an immediate crash, but a delayed hang after a seemingly successful view switch.

Environment

• Hardware/CPU: Intel Skylake generation (model 94, Intel Core Processor Skylake, IBRS, no TSX), /proc/cpuinfo flags include vmx ept vpid ept_ad hypervisor
• Nested virtualization: Enabled on L1 (/sys/module/kvm_intel/parameters/nested = Y)
• Version: kvmi-v7

Reproduction Steps

1. Boot L1 VM with nested virtualization enabled (vmx + ept exposed from L0).
2. Install and run KVM-VMI patched kernel + corresponding QEMU + LibVMI with KVM support.
3. Compile and run the official switch-view-example.c (from libvmi/examples/switch-view-example.c).
4. Observe:
   • Program prints success messages (e.g., "Switched to view 1", "Switched back to view 0", "Destroyed view 1").
   • No LibVMI API failure.
   • Example exits normally.
5. Wait 3–10 seconds: Host (L1) suddenly freezes completely (hard lockup).

Thank you for maintaining this project!
I'm happy to provide more details, test patches, or share L0 serial logs once configured.

[fengjian]

Additional note

Further testing shows that the hang/crash only occurs when destroying an EPT view.

If the program performs create and switch (including switching back to view 0) without calling vmi_slat_destroy(), the system remains stable.

This indicates that EPT view creation and switching are not the cause; the issue is triggered specifically by the view destruction path.

[thomasdangl]

Thanks for the detailed report. I have to admit this (and probably #71) is my fault: 9b96717 is a buggy mess.
I created the PR at the end of a research project and did not test it thoroughly enough.

Some time after #62 was merged we noticed the issues but funding ran out so they were never fixed.
AFAIK all EPT related stability issues of this project are related to this commit, except for what was discussed in libvmi/libvmi#1047.
If you need a stable system, you might be better off using the old implementation (three static EPT views).

Best,
Thomas

[fengjian]

Thanks for the honest reply and for owning the issue
I’ll follow your suggestion and try switching to the old implementation with the three static EPT views for better stability. I’ll look for the commit before #62 or an older tag and test it soon.
Thanks again!