restructure results

1 files changed, 0 insertions, 29 deletions

diff --git a/results/classifier/deepseek-2/output/hypervisor/1152 b/results/classifier/deepseek-2/output/hypervisor/1152
deleted file mode 100644
index e449acec..00000000
--- a/results/classifier/deepseek-2/output/hypervisor/1152
+++ /dev/null
@@ -1,29 +0,0 @@
-
-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?