1 files changed, 36 insertions, 0 deletions

diff --git a/gitlab/issues/target_i386/host_x86/accel_KVM/1152.toml b/gitlab/issues/target_i386/host_x86/accel_KVM/1152.toml
new file mode 100644
index 000000000..a81178c00
--- /dev/null
+++ b/gitlab/issues/target_i386/host_x86/accel_KVM/1152.toml
@@ -0,0 +1,36 @@
+id = 1152
+title = "Windows crashes on resuming from sleep if hv-tlbflush is enabled"
+state = "opened"
+created_at = "2022-08-12T09:17:41.461Z"
+closed_at = "n/a"
+labels = ["accel: KVM", "host: x86", "target: i386"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1152"
+host-os = "Arch Linux"
+host-arch = "x86_64 Intel i9-12900K"
+qemu-version = "7.0.0"
+guest-os = "Windows 10 21H2"
+guest-arch = "x86_64"
+description = """The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case)."""
+reproduce = """1. Boot Windows
+2. Tell Windows to go to sleep (observe that qemu's state switches to suspended)
+3. Cause windows to wake up (e.g. using the `system_wakeup` HMP command)"""
+additional = """Looking at the crash dumps always shows the "ATTEMPTED WRITE TO READONLY MEMORY" error, and always with this stack trace:
+
+```
+nt!KeBugCheckEx
+nt!MiRaisedIrqlFault+0x1413a6
+nt!MmAccessFault+0x4ef
+nt!KiPageFault+0x35e
+nt!MiIncreaseUsedPtesCount+0x12
+nt!MiBuildForkPte+0xc6
+nt!MiCloneVads+0x4ab
+nt!MiCloneProcessAddressSpace+0x261
+nt!MmInitializeProcessAddressSpace+0x1cb631
+nt!PspAllocateProcess+0x1d13
+nt!PspCreateProcess+0x242
+nt!NtCreateProcessEx+0x85
+nt!KiSystemServiceCopyEnd+0x25
+ntdll!NtCreateProcessEx+0x14
+```
+
+However, the process that is being created here is always `WerFault.exe`, i.e. the crash reporter. The crashing process is seemingly random. Removing `hv-tlbflush` from the command line resolves the problem. Hence, my hypothesis is that due to improper TLB flushing during wakeup, a random application on the core will crash, which spawns `WerFault.exe` which then immediately crashes again inside the kernel (also because of bad/stale TLB contents) and causes the BSOD. Perhaps one core wakes up first, requests a TLB flush, which is then *not* propagated to sleeping cores due to hv-tlbflush. Then one of those cores wakes up without the TLB flush?"""