blob: e34177eb6fa47d5f5c0b89fd1c9522cab4096e0d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
semantic: 0.913
other: 0.854
KVM: 0.763
graphic: 0.740
debug: 0.727
device: 0.624
performance: 0.622
boot: 0.565
PID: 0.536
permissions: 0.444
vnc: 0.421
socket: 0.384
files: 0.327
network: 0.323
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?
|
