diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/115 | 2 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/1152 | 29 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/1153 | 2 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/1156 | 2 |
4 files changed, 35 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/hypervisor/115 b/results/classifier/gemma3:12b/hypervisor/115 new file mode 100644 index 000000000..2d7000ab6 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/115 @@ -0,0 +1,2 @@ + +shmat fails on 32-to-64 setup diff --git a/results/classifier/gemma3:12b/hypervisor/1152 b/results/classifier/gemma3:12b/hypervisor/1152 new file mode 100644 index 000000000..e449acecd --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1152 @@ -0,0 +1,29 @@ + +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? diff --git a/results/classifier/gemma3:12b/hypervisor/1153 b/results/classifier/gemma3:12b/hypervisor/1153 new file mode 100644 index 000000000..680e9ca64 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1153 @@ -0,0 +1,2 @@ + +arm: wrong syndrome reported for FP and SIMD traps to AArch32 Hyp diff --git a/results/classifier/gemma3:12b/hypervisor/1156 b/results/classifier/gemma3:12b/hypervisor/1156 new file mode 100644 index 000000000..4da98ecd2 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1156 @@ -0,0 +1,2 @@ + +Incorrect implementation of vmsumudm instruction |