1 files changed, 31 insertions, 0 deletions

diff --git a/gitlab/issues/target_i386/host_missing/accel_KVM/2582.toml b/gitlab/issues/target_i386/host_missing/accel_KVM/2582.toml
new file mode 100644
index 000000000..aa1f9453e
--- /dev/null
+++ b/gitlab/issues/target_i386/host_missing/accel_KVM/2582.toml
@@ -0,0 +1,31 @@
+id = 2582
+title = "CR4.VMX leaks from L1 into L2 on Intel VMX"
+state = "opened"
+created_at = "2024-09-21T16:43:21.657Z"
+closed_at = "n/a"
+labels = ["TestCase", "accel: KVM", "target: i386"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2582"
+host-os = "NixOS unstable"
+host-arch = "x86_64 (Intel!)"
+qemu-version = "8.2.6"
+guest-os = "Custom see below, but can also be reproduced with nested virtualization"
+guest-arch = "x86_64"
+description = """In a nested virtualization setting, `savevm` can cause CR4 bits from leaking from L1 into L2. This causes general-protection faults in certain guests.
+
+The L2 guest executes this code:
+
+```
+mov rax, cr4  ; Get CR4​
+mov rcx, rax  ; Remember the old value​
+btc rax, 7    ; Toggle CR4.PGE​
+mov cr4, rax  ; #GP! <- Shouldn't happen!​
+mov cr4, rcx  ; Restore old value
+```
+
+If the guest code is interrupted at the right time (e.g. via `savevm`), Qemu marks CR4 dirty while the guest executes L2 code. Due to really complicated KVM semantics, this will result in L1 CR4 bits (VMXE) leaking into the L2 guest and the L2 will die with a GP:
+
+Instead of the expected CR4 value, the L2 guest reads a value with VMXE set. When it tries to write this back into CR4, this triggers the general protection fault."""
+reproduce = """This is only an issue on **Intel** systems.
+
+#"""
+additional = """See also this discussion where we discussed a (flawed) approach to fixing this in KVM: https://lore.kernel.org/lkml/Zh6WlOB8CS-By3DQ@google.com/t/"""