From nobody Mon Feb 9 17:14:30 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kalray.eu ARC-Seal: i=1; a=rsa-sha256; t=1644848598; cv=none; d=zohomail.com; s=zohoarc; b=Vwsc20aI7LoIYmA1bLIOV0sSoPNsEDHZEQUXCG10RV68VkBciSSv5FTk8CMHtPQCLWv1kxiEJCN6K3IuFzr/62MxZ3n9mNrjrp4OqS+QZRE2xWqQoGoVUY983kwWMYYEvoEEG9JyuCM2funPeg8TWpbG3Iu7q2L8iW5EKHL14dY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1644848598; h=Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:Sender:Subject:To; bh=avs1+E3HdP016j80CtHlqh8NCWuNNIFczqLikOUjyro=; b=mOkg1hoOk1aqV5jXVr+6TtRcJUhkNlJMiqwBtQdGZlS73MlEhqEy0R88aPKOQrZ2Os0bWkLnsPFDrN/Mo/47VdnyT6xX6fYqNzVsRRQjz6gAOE/8BY+cb/bjWq9dYSwMkGnZLB+8Cw7td5aHuRiVgBbsL20/2LYKtXFbLBoSK1s= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1644848598738754.945719900051; Mon, 14 Feb 2022 06:23:18 -0800 (PST) Received: from localhost ([::1]:42318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nJcG6-00079V-MM for importer@patchew.org; Mon, 14 Feb 2022 09:23:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJbOZ-0007En-TY for qemu-devel@nongnu.org; Mon, 14 Feb 2022 08:28:01 -0500 Received: from mxout.security-mail.net ([85.31.212.46]:61964 helo=fx303.security-mail.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJbOX-0004dS-Es for qemu-devel@nongnu.org; Mon, 14 Feb 2022 08:27:59 -0500 Received: from localhost (localhost [127.0.0.1]) by fx303.security-mail.net (Postfix) with ESMTP id A29711C3361 for ; Mon, 14 Feb 2022 14:27:51 +0100 (CET) Received: from fx303 (localhost [127.0.0.1]) by fx303.security-mail.net (Postfix) with ESMTP id B4DBE1C33E7; Mon, 14 Feb 2022 14:27:50 +0100 (CET) Received: from zimbra2.kalray.eu (unknown [217.181.231.53]) by fx303.security-mail.net (Postfix) with ESMTPS id 5B6471C33CB; Mon, 14 Feb 2022 14:27:50 +0100 (CET) Received: from zimbra2.kalray.eu (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTPS id 3D2CB27E040E; Mon, 14 Feb 2022 14:27:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id 2569D27E040D; Mon, 14 Feb 2022 14:27:50 +0100 (CET) Received: from zimbra2.kalray.eu ([127.0.0.1]) by localhost (zimbra2.kalray.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id diOo5F-uHeH1; Mon, 14 Feb 2022 14:27:50 +0100 (CET) Received: from ws2101.lin.mbt.kalray.eu (unknown [192.168.36.68]) by zimbra2.kalray.eu (Postfix) with ESMTPSA id 08F0B27E040E; Mon, 14 Feb 2022 14:27:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalray.eu; s=sec-sig-email; t=1644845271; bh=Z0LiL7ZtsJtzmKHmhv7FK1DekcDf7qm2jfvY9Bmun1A=; h=From:To:Cc:Subject:Date; b=mPZmoFV1hvJREHGhZPKUFbH+eFLJuxYNQ3RSAEdVyEDXwPQc8MJRt8tf2Fb26wMBd AB2+5d1r24898AqwiJ3PSt0n/ByS1acNpa+DQI61Pwyn0LSuvYleaon9s2Kv1KyOHY ojf6bYUVhHhBz/5qQx9HiHuYSLhNrJaFcTYiPH7s= X-Virus-Scanned: E-securemail Secumail-id: <728d.620a58d6.5a627.0> DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra2.kalray.eu 2569D27E040D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kalray.eu; s=32AE1B44-9502-11E5-BA35-3734643DEF29; t=1644845270; bh=avs1+E3HdP016j80CtHlqh8NCWuNNIFczqLikOUjyro=; h=From:To:Date:Message-Id; b=EUMqnN3L/n507gaDzEfLPHh74GwhPAvu0fuxqxLCIKo3l6DRelKkSuzH16Uw36PJc UGagFPFvvtLt8nhHw/iHtWmHr1EGYG53TRxDkuwi5df7Fn69SeNTHYFKWRO2NzFsUV Dt0Q/ZLC8AtJf3+QJcRAK+7Jjt8Bs5wMxsNqVhOE= From: Luc Michel To: qemu-devel@nongnu.org Cc: Luc Michel , Richard Henderson , Peter Maydell , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Paolo Bonzini Subject: [PATCH] accel/tcg/cpu-exec: fix precise single-stepping after interrupt Date: Mon, 14 Feb 2022 14:26:56 +0100 Message-Id: <20220214132656.11397-1-lmichel@kalray.eu> X-Mailer: git-send-email 2.17.1 X-Virus-Scanned: by Secumail Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=85.31.212.46; envelope-from=lmichel@kalray.eu; helo=fx303.security-mail.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @kalray.eu) X-ZM-MESSAGEID: 1644848630282100003 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" In some cases, cpu->exit_request can be false after handling the interrupt, leading to another TB being executed instead of returning to the main loop. Fix this by returning true unconditionally when in single-step mode. Fixes: ba3c35d9c4026361fd380b269dc6def9510b7166 Signed-off-by: Luc Michel --- Coming back on this issue I worked on with Richard in 2020. The issue is that when debugging the guest with GDB, the first instruction of the IRQ handler is missed by GDB (it's still executed though). It happened to me again in TCG RR mode (but not in MTTCG). It seems that cpu->exit_request can be false in RR mode when returning from cc->tcg_ops->cpu_exec_interrupt, leading to cpu_handle_interrupt returning false and the next TB being executed, instead of the EXCP_DEBUG being handled. --- accel/tcg/cpu-exec.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c index 8b4cd6c59d..74d7f83f34 100644 --- a/accel/tcg/cpu-exec.c +++ b/accel/tcg/cpu-exec.c @@ -796,13 +796,17 @@ static inline bool cpu_handle_interrupt(CPUState *cpu, /* * After processing the interrupt, ensure an EXCP_DEBUG is * raised when single-stepping so that GDB doesn't miss the * next instruction. */ - cpu->exception_index =3D - (cpu->singlestep_enabled ? EXCP_DEBUG : -1); - *last_tb =3D NULL; + if (unlikely(cpu->singlestep_enabled)) { + cpu->exception_index =3D EXCP_DEBUG; + return true; + } else { + cpu->exception_index =3D -1; + *last_tb =3D NULL; + } } /* The target hook may have updated the 'cpu->interrupt_reques= t'; * reload the 'interrupt_request' value */ interrupt_request =3D cpu->interrupt_request; } --=20 2.17.1