On 2018-02-17 14:27, Alex Bennée wrote: > > Jan Kiszka <jan.kis...@web.de> writes: > >> On 2018-02-17 09:56, Jan Kiszka wrote: >>> On 2017-02-16 15:31, Paolo Bonzini wrote: >>>> From: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> >>>> >>>> When GDB issues a "vCont", QEMU was not handling it correctly when >>>> multiple VCPUs are active. >>>> For vCont, for each thread (VCPU), it can be specified whether to >>>> single step, continue or stop that thread. The default is to stop a >>>> thread. >>>> However, when (for example) "vCont;s:2" is issued, all VCPUs continue >>>> to run, although all but VCPU nr 2 are to be stopped. >>>> >>>> This patch completely rewrites the vCont parsing code. >>>> >>>> Please note that this improvement only works in system emulation mode, >>>> when in userspace emulation mode the old behaviour is preserved. >>>> >>>> Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> >>>> Message-Id: <1487092068-16562-3-git-send-email-imbre...@linux.vnet.ibm.com> >>>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> >>>> --- >>>> gdbstub.c | 209 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++-------------- >>>> 1 file changed, 162 insertions(+), 47 deletions(-) >>>> > <snip> >>> >>> Seems like no one is doing guest debugging with kvm on x86 except me, >>> and I'm only doing it too infrequently now: This one broke that use case >>> for SMP guests long ago. How was it tested? >>> >>> To reproduce the bug: set up an x86-64 guest kernel with > 1 core, break >>> on some prominent syscall entry (e.g. sys_execve), continue the guest on >>> hit and it will quickly lock up, even after disabling the breakpoint >>> again. Kernel version doesn't matter (was my first guess), gdb is >>> 7.7.50.20140604-cvs (OpenSUSE) here. > > I thought I fixed this with 5a6a1ad181c658b810041d852b290ac836965aca > > FWIW I do periodically test ARM TCG and KVM guest debug using: > > tests/guest-debug/test-gdbstub.py > > But we are missing a nice integration to get an appropriate guest image > to automate this process. If we can fix that we should be able to turn > on the test as part of make check. >
If that test above is extended with more interesting setups, that should
be enough. E.g., you can reproduce this issue by running qemu with -smp
4 and the following test modifications.
diff --git a/tests/guest-debug/test-gdbstub.py
b/tests/guest-debug/test-gdbstub.py
index 31ba6c943a..a55782fa9a 100644
--- a/tests/guest-debug/test-gdbstub.py
+++ b/tests/guest-debug/test-gdbstub.py
@@ -15,6 +15,7 @@ def report(cond, msg):
print ("PASS: %s" % (msg))
else:
print ("FAIL: %s" % (msg))
+ global failcount
failcount += 1
@@ -33,6 +34,7 @@ def check_break(sym_name):
bp = gdb.Breakpoint(sym_name)
gdb.execute("c")
+ gdb.execute("c 100")
# hopefully we came back
end_pc = gdb.parse_and_eval('$pc')
@@ -138,12 +140,12 @@ def run_test():
# Can't set this up until we are in the kernel proper
# if we make it to run_init_process we've over-run and
# one of the tests failed
- print ("Setup catch-all for run_init_process")
- cbp = CatchBreakpoint("run_init_process")
- cpb2 = CatchBreakpoint("try_to_run_init_process")
+ #print ("Setup catch-all for run_init_process")
+ #cbp = CatchBreakpoint("run_init_process")
+ #cpb2 = CatchBreakpoint("try_to_run_init_process")
print ("Checking Normal breakpoint works")
- break_ok = check_break("wait_for_completion")
+ break_ok = check_break("SyS_execve")
report(break_ok, "break @ wait_for_completion")
print ("Checking watchpoint works")
With -smp 1, check_break succeeds.
Jan
signature.asc
Description: OpenPGP digital signature
