1 files changed, 88 insertions, 0 deletions
diff --git a/results/classifier/118/review/1152 b/results/classifier/118/review/1152
new file mode 100644
index 00000000..e6fbb475
--- /dev/null
+++ b/results/classifier/118/review/1152
@@ -0,0 +1,88 @@
+semantic: 0.913
+architecture: 0.776
+KVM: 0.763
+graphic: 0.740
+debug: 0.727
+device: 0.624
+performance: 0.622
+register: 0.615
+x86: 0.611
+boot: 0.565
+PID: 0.536
+ppc: 0.479
+i386: 0.453
+permissions: 0.444
+risc-v: 0.434
+vnc: 0.421
+kernel: 0.404
+VMM: 0.385
+socket: 0.384
+mistranslation: 0.380
+files: 0.327
+network: 0.323
+peripherals: 0.265
+TCG: 0.252
+arm: 0.224
+hypervisor: 0.167
+virtual: 0.159
+assembly: 0.150
+user-level: 0.070
+--------------------
+debug: 0.954
+virtual: 0.950
+kernel: 0.904
+TCG: 0.375
+x86: 0.270
+hypervisor: 0.101
+performance: 0.075
+PID: 0.031
+files: 0.023
+VMM: 0.019
+socket: 0.018
+register: 0.015
+user-level: 0.011
+i386: 0.010
+architecture: 0.008
+device: 0.008
+assembly: 0.007
+boot: 0.005
+semantic: 0.005
+network: 0.002
+permissions: 0.002
+graphic: 0.002
+risc-v: 0.001
+peripherals: 0.001
+mistranslation: 0.001
+KVM: 0.000
+vnc: 0.000
+ppc: 0.000
+arm: 0.000
+
+Windows crashes on resuming from sleep if hv-tlbflush is enabled
+Description of problem:
+The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case).
+Steps to 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 information:
+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?