From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 97637D13596 for ; Mon, 28 Oct 2024 11:27:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cAjlSlzvN257TW7uK2g5sFs4IlzrIWWNOtSATOulIFs=; b=k5LF5f7zfOyANj3Cl05AxNMQcR Yx7E7vj7TCEQlpwNKO2y/wAvc2DGv8clLedwJL7RGyGdLLRjK6xjT6Yi6u6m22y4q9vp/zwg23Tsq ctDwgj98Zfusl+CnfO/1SGfB1HPRfLSDE7VlP9E8QUKY5MH56k4rFFBFiHgRnlKwKSLZBnuCWRhxL MwSAt9V0Oe6RRerE1ZFVwOZd3mc8Udhy/p9qGoVPZ5GSyKHtYJ8G7bBaILddP/mEs8oXE+LBjeVem hTnVZUvBCfZfisojBBfG6kz6AdZPUyVHk6cQkuwDx7iOs3vyCffys8YJLwDMWrXf6cFlNLXRnGpkg 3EWFIH5Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t5Nu7-0000000Aa0k-0T5M; Mon, 28 Oct 2024 11:27:23 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t5NqU-0000000AZCn-0emr for linux-arm-kernel@bombadil.infradead.org; Mon, 28 Oct 2024 11:23:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Type:MIME-Version:References: In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=cAjlSlzvN257TW7uK2g5sFs4IlzrIWWNOtSATOulIFs=; b=lEqSP5Yn3ytW8QxQhERT5CKnsL 1kPzfVwkxs0ZMWzKNkdJ3FK2AHpA4x3i9T3pdmskPKBkaEbGJ4pCd+n0J1kBQ37P/ck7waMshcOko ml+JXgli3jwGHZktbWWDYtZxBRV8awdxcX6duGMHKipiZedODpoY+TfLffsJ/WtcHLx2GMjfy256I 6U/+bBdnB7vp/5DQrMn+i0aHQ5Yxvr6tk/lSeoq2vnmqg2/sGnY9FPoxHPjNBwUtY8hkTP7aK3qCc YFhRFiG7suLJUoaLhAgWfyYjg5YXirANZ/30DcQpvZ3Sy+1kxwVz5saUytKVbiKlUWrnBj8dmEzqr g4+u0CkA==; Received: from nyc.source.kernel.org ([147.75.193.91]) by desiato.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t5NqR-00000009fSd-1Gcs for linux-arm-kernel@lists.infradead.org; Mon, 28 Oct 2024 11:23:37 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CAA81A41E1D; Mon, 28 Oct 2024 11:21:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9BB3C4CEC3; Mon, 28 Oct 2024 11:23:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730114613; bh=QZ9AopNucVMqrwP40XJs/p49YjzYKaVfPzmSbTJGD3Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IGvAAdp4fgglzP1wMlIDiYZZYKYS/wp7kYN2A24SOjV+eO1dIeKXo+q9gdxaillX6 lmY0qmR9n/+HtAZrnr2f38j6BMpjRiFMdssDLLrBaPz2O51NX3fPgMxiEdLJATbdOd cLPRVlThRpudgcMz4hcYCVOww0MkO3DQdxgR2x8IOzWgBNb/h34LooM1MKGni+yFvK tV8Mwrmd85c9bpt6pW7GoKVjL+YLXqHPlQoD60/4qQ/FNDiSiVbeAERXkHsXrDXT90 6yx/s2Ke8tRoJK9/pZTwPg7SX3WNq5MvF67pEsrqhyZpXX97rmPVMSc0xSyXztsl+v VeasRJjDHfjWg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1t5NqM-007XwE-Is; Mon, 28 Oct 2024 11:23:30 +0000 Date: Mon, 28 Oct 2024 11:23:30 +0000 Message-ID: <86ed4031zh.wl-maz@kernel.org> From: Marc Zyngier To: puranjay@kernel.org Cc: Arnd Bergmann , "Arnd\ Bergmann" , Alex =?UTF-8?B?QmVubsOpZQ==?= , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Sumit Garg , puranjay12@gmail.com, Ard Biesheuvel , Oliver Upton , Suzuki K Poulose , Joey Gouly , Zenghui Yu Subject: Re: Supporting KVM_GUESTDBG_BLOCKIRQ or something similar on ARM64 In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: puranjay@kernel.org, arnd@arndb.de, arnd@kernel.org, alex.bennee@linaro.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, sumit.garg@linaro.org, puranjay12@gmail.com, ardb@kernel.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, joey.gouly@arm.com, zenghui.yu@linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241028_112335_599396_69A6BA1C X-CRM114-Status: GOOD ( 25.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org [+ArdB, which I assume you really wanted to Cc on this, as well as the KVM/arm64 stakeholders] On Mon, 28 Oct 2024 10:53:34 +0000, puranjay@kernel.org wrote: > > Hi Everyone, > > I work on the BPF JIT for arm64 and regularly use Qemu with gdb for > debugging by single stepping parts of the code. I realized that whenever > I enable KVM, single stepping doesn't work as expected and it lands in an > interrupt handler. I disagree. Single-stepping works *exactly* as you should expect, by not interfering with the rest of the system. > It always worked for me on x86 so I looked in the source code and found > that x86 supports KVM_GUESTDBG_BLOCKIRQ that blocks IRQs when single > stepping. Right, and that is not an architectural behaviour, but something that helps the person running the debugger. I'm not saying it is not useful, but that this is an *additional* behaviour that the architecture is not supposed to cover. Also, given that KVM_GUESTDBG_BLOCKIRQ has *zero* documentation, nobody felt compelled to implement it. I didn't even know of its existence until you mentioned it. > I assume that arm64 doesn't support KVM_GUESTDBG_BLOCKIRQ because it is > not trivial to implement this on arm64 due to some architectural > limitations? There was a patch [1] posted in 2022 to solve this issue > but it was not merged. That patch does the wrong thing when it comes to KVM. We are not building a Linux-only hypervisor, and we need a solution that works irrespective of the guest. > Let's start a discussion about what needs to be done to support this on > arm64. A good start would be to define the semantics of such a flag: - what should it affect? the vcpu you are single-stepping? all vcpu? - should userspace to know that interrupts are pending? - should this result in any effect on the guest's view of time? - what of interactions on the rest of the system (such as devices)? Thanks, M. -- Without deviation from the norm, progress is not possible.