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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
architecture: 0.948
KVM: 0.931
graphic: 0.916
ppc: 0.902
user-level: 0.887
debug: 0.880
performance: 0.869
virtual: 0.852
semantic: 0.848
files: 0.810
assembly: 0.769
socket: 0.761
kernel: 0.740
vnc: 0.739
peripherals: 0.726
device: 0.711
permissions: 0.708
risc-v: 0.708
register: 0.690
network: 0.688
mistranslation: 0.657
PID: 0.602
boot: 0.520
hypervisor: 0.518
x86: 0.505
VMM: 0.492
arm: 0.485
i386: 0.358
TCG: 0.324
repeated KVM single step crashes leaks into SMP guest and crashes guest application
Guest: Windows 7 x64
Host: Ubuntu 18.04.4 (kernel 5.3.0-40-generic)
QEMU: master 6c599282f8ab382fe59f03a6cae755b89561a7b3
If I try to use GDB to repeatedly single-step a userspace process while running a KVM guest, the userspace process will eventually crash with a 0x80000004 exception (single step). This is easily reproducible on a Windows guest, I've not tried another guest type but I've been told it's the same there also.
On a Ubuntu 16 host with an older kernel, this will hang the entire machine. However, it seems it may have been fixed by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cc244a20b86090c087073c124284381cdf47234 ?
It's not clear to me whether this is a KVM or a QEMU bug. A TCG guest does not crash the userspace process in the same way, but it does hang the VM.
I've tried a variety of QEMU versions (3.0, 4.2, master) and they all exhibit the same behavior. I'm happy to dig into this more if someone can point me in the right direction.
Here's the outline for reproducing the bug:
* Compile iloop.cpp (attached) as a 32-bit application using MSVC
* Start Windows 7 x64 guest under GDB
* Pass '-enable-kvm -smp 4,cores=2 -gdb tcp::4567' to QEMU along with other typical options
(need to get CR3 to ensure we're in the right application context -- if there's an easier way to do this I'd love to hear it!)
* Install WinDBG on guest
* Copy SysInternals LiveKD to guest
* Start iloop.exe in guest, note loop address
* Run LiveKD from administrative prompt
* livekd64.exe -w
* In WinDBG:
* !process 0 0
* Search for iloop.exe, note DirBase (this is CR3)
In GDB:
* Execute 'target remote tcp::4567'
* Execute 'c'
* Hit CTRL-C to pause the VM
* Execute 'p/x $cr3'
.. continue if not equal to DirBase in WinDBG, keep stopping until it is equal
* Once $cr3 is correct value, if you 'stepi' a few times you'll note the process going in a loop, it should keep hitting the address echoed to the console by iloop.exe
Crash the process from GDB:
* Execute 'stepi 100000000'
* Watch the process, eventually it'll die with an 0x80000004 error
Some experimentation with newer kernels indicate that this is most likely a KVM bug.
|