From patchwork Sat Feb 17 17:00:07 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jan Kiszka X-Patchwork-Id: 10226257 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 79FFE601D4 for ; Sat, 17 Feb 2018 17:03:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63BAC28991 for ; Sat, 17 Feb 2018 17:03:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 58401289CE; Sat, 17 Feb 2018 17:03:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B5D3428991 for ; Sat, 17 Feb 2018 17:03:56 +0000 (UTC) Received: from localhost ([::1]:40942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en5ty-0006aT-Ir for patchwork-qemu-devel@patchwork.kernel.org; Sat, 17 Feb 2018 12:03:54 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en5ql-0005Jo-Kc for qemu-devel@nongnu.org; Sat, 17 Feb 2018 12:00:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1en5qi-0006rw-In for qemu-devel@nongnu.org; Sat, 17 Feb 2018 12:00:35 -0500 Received: from mout.web.de ([212.227.15.3]:47157) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1en5qi-0006rU-5z for qemu-devel@nongnu.org; Sat, 17 Feb 2018 12:00:32 -0500 Received: from [192.168.1.10] ([95.157.57.47]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0M4Zps-1eYpfs2ecO-00ye4k; Sat, 17 Feb 2018 18:00:12 +0100 To: =?UTF-8?Q?Alex_Benn=c3=a9e?= References: <1487255507-106654-1-git-send-email-pbonzini@redhat.com> <1487255507-106654-10-git-send-email-pbonzini@redhat.com> <3f632c5b-56b8-340c-02bd-f66abccd9473@web.de> <87k1vb7nkw.fsf@linaro.org> From: Jan Kiszka Message-ID: <1ade39bb-3573-e0e0-6b9f-9d23264b9f06@web.de> Date: Sat, 17 Feb 2018 18:00:07 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <87k1vb7nkw.fsf@linaro.org> X-Provags-ID: V03:K0:IqsPPUQLyL/UttQ2dJ+qrb+Ak1PCmCPyRJvIMud/dVpIIDb0WE4 ABEybuwTqUShIHQZjtz+AvQ0NXTypfZ93SRofsVDC4xRLXFFqnqSas323qbdzNBeLAQQQsP p8SMzk/A4tKWW3v4U3ZPoBNKUJopZa/8JROla4kgxSQOGaS9V48uLS3kIBLOrijCCApG8VH XNwhbBpHElhsmncs52xuQ== X-UI-Out-Filterresults: notjunk:1; V01:K0:rWDpyExX4iw=:Yi+9N8uB7BCDdvVL1FyLGe 8OarMTB0dn9NeJxMV+EOoFEF0qYnc/OILwh6LUdrc75PtvAC+BW3ALX+bIrGYy+jeImGX+l0Y IrTNK25RBheoVU3Qr/kXj+xRpggDuQG3jxM3Y0dgv+3E5uFK6Ich0xMlsBetGe6otCM2Q/GH5 lr6iDJBStzQvC0BRn9OO+Yr3ZlgOAPdrZMZS54qiAAWVH8e+PlSYBNpTMTrJAU5G62fm3vHHk 7856NqVaR7gh0sNaglybl3UJV5LghrU3CO2nrmt7/x8eXjqp0CAiauNFDI+W+Hhb0zThy90jV 3YO2weK5pAPrT9P++PWUnm/l3MpKDA92LUkDvz5W9yAa2utwtEz2j9l0Odx3FIh6ow7hDiDmY adwZldGiEZuzyjrNE5qQ9rCkz52kLVfWCq6fb6u+2Amops4VBf26Oj4pjlSK77UnYnkPV5EWX CjtYNCMtKK4emap5I4dyWuVbEe3VofYwOtTtJw2revEUKyGJE3hdcU4Z10bp/Ev8xA3ZbNZ2z NlwXMRtyxLO+2Pw22/yNd9bVDKXBze1NlpDSqOyHS0MX1tXMsNqjHtgYQQKxc+p7dngYcz4dE DJvM84XP1kkZbgAr3LTJLreMlRHE8dWihsOZTxwHSobmIRB/ipQmpguGZLAt4DvPMecbgE7HM jrFW2Mb6IG0andX7fU/5bgLGcyMsJ1qqvAKwrK9Nngk0Vr260fabY7/IcTfBimdgv3jdIShgm m8MSjSsmCDBpiJqaIzJWR7ZpP9KWzYEf5NgqhqUVg7uf+01h+4lrogAk3YkDmxYTUFjYvxypv 3GvylLokb2yEqYnJwLZuy998B80gg== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.3 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [Qemu-devel] [PULL 09/23] gdbstub: Fix vCont behaviour X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , qemu-devel@nongnu.org, Claudio Imbrenda Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 2018-02-17 14:27, Alex Bennée wrote: > > Jan Kiszka writes: > >> On 2018-02-17 09:56, Jan Kiszka wrote: >>> On 2017-02-16 15:31, Paolo Bonzini wrote: >>>> From: Claudio Imbrenda >>>> >>>> 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 >>>> Message-Id: <1487092068-16562-3-git-send-email-imbrenda@linux.vnet.ibm.com> >>>> Signed-off-by: Paolo Bonzini >>>> --- >>>> gdbstub.c | 209 ++++++++++++++++++++++++++++++++++++++++++++++++-------------- >>>> 1 file changed, 162 insertions(+), 47 deletions(-) >>>> > >>> >>> 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. With -smp 1, check_break succeeds. Jan 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")