From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E64054765 for ; Mon, 28 Oct 2024 11:23:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730114613; cv=none; b=giYMYWXaVK/qVyjSPqT0LUqVLw8PO6Ms852+O7mfz4d2Sw3MAfxZTbR20+lKurfAycYLYSG6WW09cKdrZbOauv8kHrpR5eJjmlFMedANNAxPqrgGvayLYmYegqDKwvPI59879VkvJnrr5wJEaag58FDRIOJpSP229RCHc9ufX94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730114613; c=relaxed/simple; bh=QZ9AopNucVMqrwP40XJs/p49YjzYKaVfPzmSbTJGD3Y=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=iXC9BX9VU0OFp0n3/kC3NfYyiEH6HflhLlHx21E89VcvE6Ph4zO/mArG2es/p8R2bv08gtV5yiTP1nizsYoRlepeGWs9gSrbF0aNHsuBn+9UcsK1K2QTdpLmbBN1yC9BHf/xietn92J3b0sFvqiTleQ+TYu8clQisYQhX6mRmZw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IGvAAdp4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IGvAAdp4" 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) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 [+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.