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 127C9C433EF for ; Mon, 29 Nov 2021 14:17:27 +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=NHOyCdaVX+17jk8NSf8WNo8oxSqkLS2Tfc+/sQBYHD4=; b=KpJKY/gf3O0N0O NkDNIzvJkEuSTPJL7W5LvPjlWKPUf90HMr280biGx8tVHf5NuthPA6qVeOMr3X8YhviMBQtQ1YWi1 tRA9nuhd/LhRXlfUfvecM5xcvPtBzWxIc7CvnHbNEoasYUgDofWFSRNKJM7d907WNHUZje1bxHsda yH2OpdtTMTn+x3gOm4LayRJ/dDjwLN3CM4j82GMVk8VnWu0pZx1Jrj4raJhnPJzQME7cU0pFCj4gk WJsOvRdriOtMfMX9yUNDJ8ruoh5bhGZ66sVGoskZi3gh8utRq0a2x0Fo6eLfGAd20AtFTQM5C/RgZ 0upUrgvmMXXje7Vzqlgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mrhRl-000yd7-1C; Mon, 29 Nov 2021 14:15:57 +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 1mrhRg-000ybB-6C for linux-arm-kernel@lists.infradead.org; Mon, 29 Nov 2021 14:15:54 +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 D86D0B8111B; Mon, 29 Nov 2021 14:15:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C8B6C004E1; Mon, 29 Nov 2021 14:15:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638195349; bh=UafrWDpBzGQxBXiEJaJ0VnLb5yrvQUuaKKagwroBrRo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Fz1DeVyRoqqZrgN6nOtkwIIckdliEFh79ZJsS8ldTUdgoN3r/z5i8hAESQbexQDFb LPYz6Zmqa2zZGQKLibdihmacOgnAQb4tK3cvUpvUOLGkWO3GyKMjm0WuYQ+9yeeigj 2tn4g0SMzf1hoRdMERSpGo8jRpT/thrX3uIszvtJLCkhFRMbNQm9QULVyFV+pCMZGr QaJEzjj9C0s0My6JRwnYm4a1KO/gX1YrvxmzJVTolEKUHe0Bb7CUnU1jjxuMxvD42I X9q8W3wnSU8ENEkKjQVODkxTXYJxl+Edg36+Zh28zjwB5QDTAOr+K7EEz2NFOQ9Ame zSPJSw2TttmCA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mrhRb-008cMI-7I; Mon, 29 Nov 2021 14:15:47 +0000 Date: Mon, 29 Nov 2021 14:15:46 +0000 Message-ID: <87r1azm4j1.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones , Peter Shier , Ricardo Koller , Reiji Watanabe Subject: Re: [PATCH v3 4/6] KVM: arm64: Emulate the OS Lock In-Reply-To: <20211123210109.1605642-5-oupton@google.com> References: <20211123210109.1605642-1-oupton@google.com> <20211123210109.1605642-5-oupton@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: oupton@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, drjones@redhat.com, pshier@google.com, ricarkol@google.com, reijiw@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-20211129_061552_530544_C2B7E4C8 X-CRM114-Status: GOOD ( 39.52 ) 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 On Tue, 23 Nov 2021 21:01:07 +0000, Oliver Upton wrote: > > The OS lock blocks all debug exceptions at every EL. To date, KVM has > not implemented the OS lock for its guests, despite the fact that it is > mandatory per the architecture. Simple context switching between the > guest and host is not appropriate, as its effects are not constrained to > the guest context. > > Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby > blocking all but software breakpoint instructions. To handle breakpoint > instructions, trap debug exceptions to EL2 and skip the instruction. Skipping breakpoint instructions? I don't think you can do that, as the guest does rely on BRK always being effective. I also don't see where you do that... > > Signed-off-by: Oliver Upton > --- > arch/arm64/include/asm/kvm_host.h | 4 ++++ > arch/arm64/kvm/debug.c | 27 +++++++++++++++++++++++---- > arch/arm64/kvm/sys_regs.c | 6 +++--- > 3 files changed, 30 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 53fc8a6eaf1c..e5a06ff1cba6 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -726,6 +726,10 @@ void kvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu); > void kvm_arm_setup_debug(struct kvm_vcpu *vcpu); > void kvm_arm_clear_debug(struct kvm_vcpu *vcpu); > void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu); > + > +#define kvm_vcpu_os_lock_enabled(vcpu) \ > + (!!(__vcpu_sys_reg(vcpu, OSLSR_EL1) & SYS_OSLSR_OSLK)) > + > int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu, > struct kvm_device_attr *attr); > int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu, > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c > index db9361338b2a..7835c76347ce 100644 > --- a/arch/arm64/kvm/debug.c > +++ b/arch/arm64/kvm/debug.c > @@ -53,6 +53,14 @@ static void restore_guest_debug_regs(struct kvm_vcpu *vcpu) > vcpu_read_sys_reg(vcpu, MDSCR_EL1)); > } > > +/* > + * Returns true if the host needs to use the debug registers. > + */ > +static inline bool host_using_debug_regs(struct kvm_vcpu *vcpu) > +{ > + return vcpu->guest_debug || kvm_vcpu_os_lock_enabled(vcpu); Just the name of the function has sent my head spinning. Even if the *effects* of the host debug and the OS Lock are vaguely similar from the guest PoV, they really are different things, and I'd rather not lob them together. > +} > + > /** > * kvm_arm_init_debug - grab what we need for debug > * > @@ -105,9 +113,11 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu) > * - Userspace is using the hardware to debug the guest > * (KVM_GUESTDBG_USE_HW is set). > * - The guest is not using debug (KVM_ARM64_DEBUG_DIRTY is clear). > + * - The guest has enabled the OS Lock (debug exceptions are blocked). > */ > if ((vcpu->guest_debug & KVM_GUESTDBG_USE_HW) || > - !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY)) > + !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY) || > + kvm_vcpu_os_lock_enabled(vcpu)) > vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA; > > trace_kvm_arm_set_dreg32("MDCR_EL2", vcpu->arch.mdcr_el2); > @@ -160,8 +170,10 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) > > kvm_arm_setup_mdcr_el2(vcpu); > > - /* Is Guest debugging in effect? */ > - if (vcpu->guest_debug) { > + /* > + * Check if we need to use the debug registers. > + */ > + if (host_using_debug_regs(vcpu)) { I'd rather you expand the helper here and add the comment you have in the commit message explaining the machine-wide effect of the OS Lock. > /* Save guest debug state */ > save_guest_debug_regs(vcpu); > > @@ -223,6 +235,10 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) > trace_kvm_arm_set_regset("WAPTS", get_num_wrps(), > &vcpu->arch.debug_ptr->dbg_wcr[0], > &vcpu->arch.debug_ptr->dbg_wvr[0]); > + } else if (kvm_vcpu_os_lock_enabled(vcpu)) { > + mdscr = vcpu_read_sys_reg(vcpu, MDSCR_EL1); > + mdscr &= ~DBG_MDSCR_MDE; > + vcpu_write_sys_reg(vcpu, mdscr, MDSCR_EL1); > } > } > > @@ -244,7 +260,10 @@ void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) > { > trace_kvm_arm_clear_debug(vcpu->guest_debug); > > - if (vcpu->guest_debug) { > + /* > + * Restore the guest's debug registers if we were using them. > + */ > + if (host_using_debug_regs(vcpu)) { > restore_guest_debug_regs(vcpu); > > /* > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 5dbdb45d6d44..1346906f5c46 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1453,9 +1453,9 @@ static unsigned int mte_visibility(const struct kvm_vcpu *vcpu, > * Debug handling: We do trap most, if not all debug related system > * registers. The implementation is good enough to ensure that a guest > * can use these with minimal performance degradation. The drawback is > - * that we don't implement any of the external debug, none of the > - * OSlock protocol. This should be revisited if we ever encounter a > - * more demanding guest... > + * that we don't implement any of the external debug architecture. > + * This should be revisited if we ever encounter a more demanding > + * guest... > */ > static const struct sys_reg_desc sys_reg_descs[] = { > { SYS_DESC(SYS_DC_ISW), access_dcsw }, 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