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 67829ECAAD3 for ; Fri, 9 Sep 2022 12:42:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TtrQKocTcwsejdrKoPRxVQ86o9cE0yxL/YQnuTYLgjM=; b=Wx5zl4z9fdj68i LazgjiWv5c5kFcpKmOuvDNIApc2QoflZG4bvxILSJ3gzqAZheABKuc5j9DndVRGoJeSI0QQn9h9c5 zmvVm/BJQTueJJe8f6Z7GI6RCfSpyUjtblF54X7tShtyyjAwztsusx3T8u4VplLjB/U3FP9h2ao+W cZmnlUQltbb/9NmlqOPErhnbbfv7po77M0Kn3Aww6egkWQHPOl6JkmbAVq4Wx8hMKmFi2bTriqxZJ lGaDxmspB1ZD1ewe6Xb9kNPtFfWZSbggZpOnt1nDFEjz2z9OdRky4aGMokAaXJ9UH06tcI2eYYuPd Ka6b5PzmQAm0Run7eCxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWdKA-00G5tx-KQ; Fri, 09 Sep 2022 12:41:34 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWdK6-00G5tK-Dz for linux-arm-kernel@lists.infradead.org; Fri, 09 Sep 2022 12:41:33 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BF117B82244; Fri, 9 Sep 2022 12:41:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BB0EC433D6; Fri, 9 Sep 2022 12:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662727287; bh=CLH7ZAjFywwJOIlljcX2EP88lBse8oQ2fMjAzTCF1yk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LZ3wjBZRidQBor81kcrDhinncaY29SFDVDQ3PzjIlLQ6mFWpYjSJF+5qWZL+Qhy7w ugcS9lxO866hiuPdRIUH+zI7+C9d1hOZM0AAzGCMNBZuwgSK5r+OjJbRZ8ilX7jQdM /3grJNdunCYsCKsMA6NgsxkQna9EB3b580gEgv05Fx3UwLB2SVSvcA50PvMM7LSNIs GC6gyBHwev7AbzyslXk6zn3U6Qx0fM85kjI0b6nEEkbXuvHFZxCW8D+UVrPjJ5iL+P sWOQGG2+wSv7ScPcPW7WcWGrp5IKgwXAXw2DLZNmTFDV1KlN6iZ0qU7BgJjKXYwW1Y Wa6f+sj20S3sw== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1oWdK1-009BPp-AH; Fri, 09 Sep 2022 13:41:25 +0100 Date: Fri, 09 Sep 2022 13:41:24 +0100 Message-ID: <87bkrora8b.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH 1/3] KVM: arm64: Don't set PSTATE.SS when Software Step state is Active-pending In-Reply-To: <20220909044636.1997755-2-reijiw@google.com> References: <20220909044636.1997755-1-reijiw@google.com> <20220909044636.1997755-2-reijiw@google.com> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: reijiw@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, pbonzini@redhat.com, ricarkol@google.com, oliver.upton@linux.dev, jingzhangos@google.com, rananta@google.com 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-20220909_054130_784627_696DD10B X-CRM114-Status: GOOD ( 34.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Reiji, On Fri, 09 Sep 2022 05:46:34 +0100, Reiji Watanabe wrote: > > Currently, PSTATE.SS is set on every guest entry if single-step is > enabled for the vCPU by userspace. However, it could cause extra > single-step execution without returning to userspace, which shouldn't > be performed, if the Software Step state at the last guest exit was > Active-pending (i.e. the last exit was not triggered by Software Step > exception, but by an asynchronous exception after the single-step > execution is performed). For my own enlightenment, could you describe a sequence of events that leads to this issue? > > Fix this by not setting PSTATE.SS on guest entry if the Software > Step state at the last exit was Active-pending. > > Fixes: 337b99bf7edf ("KVM: arm64: guest debug, add support for single-step") > Signed-off-by: Reiji Watanabe > --- > arch/arm64/include/asm/kvm_host.h | 3 +++ > arch/arm64/kvm/debug.c | 19 ++++++++++++++++++- > arch/arm64/kvm/guest.c | 1 + > arch/arm64/kvm/handle_exit.c | 2 ++ > 4 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index e9c9388ccc02..4cf6eef02565 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -535,6 +535,9 @@ struct kvm_vcpu_arch { > #define IN_WFIT __vcpu_single_flag(sflags, BIT(3)) > /* vcpu system registers loaded on physical CPU */ > #define SYSREGS_ON_CPU __vcpu_single_flag(sflags, BIT(4)) > +/* Software step state is Active-pending */ > +#define DBG_SS_ACTIVE_PENDING __vcpu_single_flag(sflags, BIT(5)) > + > > /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */ > #define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) + \ > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c > index 0b28d7db7c76..125cfb94b4ad 100644 > --- a/arch/arm64/kvm/debug.c > +++ b/arch/arm64/kvm/debug.c > @@ -188,7 +188,16 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) > * debugging the system. > */ > if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) { > - *vcpu_cpsr(vcpu) |= DBG_SPSR_SS; > + /* > + * If the software step state at the last guest exit > + * was Active-pending, we don't set DBG_SPSR_SS so > + * that the state is maintained (to not run another > + * single-step until the pending Software Step > + * exception is taken). > + */ > + if (!vcpu_get_flag(vcpu, DBG_SS_ACTIVE_PENDING)) > + *vcpu_cpsr(vcpu) |= DBG_SPSR_SS; I guess my confusion stems from my (probably wrong) interpretation if the SS state is A+P, there is no harm in making it pending again (setting the SS bit in PSTATE). > + > mdscr = vcpu_read_sys_reg(vcpu, MDSCR_EL1); > mdscr |= DBG_MDSCR_SS; But it looks like the *pending* state is actually stored in MDSCR instead? The spec only mentions this for the A+P state, so this is quite likely a bug indeed. Now, where does the asynchronous exception comes into play? I found this intriguing remark in the ARM ARM: The Software Step exception has higher priority than all other types of synchronous exception. However, the prioritization of this exception with respect to any unmasked pending asynchronous exception is not defined by the architecture. Is this what you were referring to in the commit message? I think you need to spell it out for us, as I don't fully understand what you are fixing nor do I understand the gory details of single-stepping... Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel