* [Bug 206707] Irregular behavior debugging userspace program on SMP guest
[not found] <bug-206707-28872@https.bugzilla.kernel.org/>
2020-02-28 22:08 ` [Bug 206707] Irregular behavior debugging userspace program on SMP guest bugzilla-daemon
@ 2020-02-28 22:30 ` bugzilla-daemon
2020-02-28 22:31 ` bugzilla-daemon
2 siblings, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2020-02-28 22:30 UTC (permalink / raw)
To: kvm
https://bugzilla.kernel.org/show_bug.cgi?id=206707
--- Comment #2 from Dustin Spicuzza (dustin@virtualroadside.com) ---
Note: I'm really sorry about the extra emails... clicked 'submit bug' when
trying to upload an attachment. Oops! Here's the actual description of the bug:
Guest: Windows 7 x64
Host: Fedora 32 (rawhide?) kernel 5.6.0-0.rc3.git0.1.fc32.x86_64
QEMU: master e0175b7163
With an SMP guest (in this case Windows 7, but we've observed issues in other
OS also), debugging userspace programs exhibits irregular behavior. On older
kernels, a single step exception would escape into the guest application. On
newer kernels, this doesn't seem to occur anymore, but instead it takes down
the whole VM with a STOP 0x00000101 BSOD.
If it would be helpful to reproduce this bug with a Linux VM, I'm happy to try
and do so -- if you could point me at an ideal QCOW2 or distribution to use for
reproducing, that would be great.
None of these errors occur with QEMU in TCG mode.
Reproduction (version 1)
------------------------
TL;DR: I created a guest application that launches multiple threads, and a gdb
script that tries to debug the guest application. This setup reliably triggers
the bugs discussed above.
iloop.exe should be compiled from iloop.cpp. I used Visual Studio as 32-bit
project. I've also uploaded the exe if you don't want to compile your own.
When you compile your own iloop.exe, you need to run it at least once and
copy/paste the output (of various offsets needed for debugging) to the top of
the gdb script.
QEMU command line:
IMG=/path/to/image
VNC=some port
ROOT=/path/to/smb/share
UUID=some uuid
~/qemu-install/bin/qemu-system-x86_64 -enable-kvm \
-m 4096 -gdb tcp::4567 -smp 4,cores=2 \
-usb -usbdevice tablet \
-net user,smb=${ROOT} -net nic,model=virtio \
-device usb-ehci,id=ehci \
-rtc base=utc,clock=vm \
-show-cursor -monitor stdio -vnc :$VNC \
-uuid $UUID -snapshot \
$IMG
When running the quest, you need to run 'iloop.exe', then run gdb with the
attached script:
gdb -x gdbs.py
Once you start gdb, it will ask for the base address of iloop.exe, which is
output when the executable is started (because ASLR). The attached script will
try to pause in the executable's context, and once it detects it, will set two
hardware breakpoints, activate the two threads and watch for breakpoints to get
hit. Each time it gets hit it will validate that the counters each thread is
incrementing are correct.
After a few hundred or few thousand breakpoints getting hit, eventually the VM
will either hang, the guest application will crash with a single step exception
(0x80000004), or the guest VM will blue screen with a STOP 0x00000101 error.
Reproduction (version 2)
------------------------
Attaching GDB, switching to the context of the process, then running 'stepi
100000' will cause similar effects as observed above. May be a separate bug,
but doubtful. See original QEMU bug report @
https://bugs.launchpad.net/qemu/+bug/1863819
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread