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 99C9AC433F5 for ; Mon, 6 Dec 2021 17:36:50 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vnAWk7L7wGSIaRZFkote8hd/7DAFTLd4xkYTN+Y/Qew=; b=imnMcHhsYnBEQ9 xq4lSUgWKE2v83MCEcO6pydDBJJuX6hWVKQMmjvhR8SkEXVVUKiHidv/CgRv+EZXeLEFVh5+18Xlo WAtXFn/LMRW+mY0cQOioLKJui+Im77CofJHz89gfLdcMJVeaQsuNw9it/MW5H2VCaMGaEZpJgd945 60r8hu2d9KWF/ILc6wunZEOgv621bTZIke0o5FiKqZychQjNC5fgS++s9PdcV4ZNgSA2IBbBUb9Xy WTXAFRUsyv66pmhLBNYYZwdTkW7IrdJHb63DycwHg2i6X37ubSfO/iprtfacDQ7YWjAe1+xr23BCv A5cdcjVXpDgEeFK0TBQQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muHtW-0055gQ-9K; Mon, 06 Dec 2021 17:35:18 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1muHtR-0055em-Pn for linux-arm-kernel@lists.infradead.org; Mon, 06 Dec 2021 17:35:15 +0000 Received: by mail-lj1-x236.google.com with SMTP id 13so22295874ljj.11 for ; Mon, 06 Dec 2021 09:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ObijjNNRXE6itlkJdDnoMy05ulET3J5ksrjco4dQA1c=; b=CLjXdyfnqAQMK6ExVkjomUn/HBbVGyHOP3vEp5iYRyMOQE3H1wp+Naco6XQH67BV3I WCZYxzsm0yUrrV+ml2Y2tSNPl+uss3Vj4fFX4i13TJ+6UM5EO3AePqtXU2/1zUE8Knxi XRd8m8wmdPGj5v7lXsHfWbstSAK91GbAG1hG8OXJtjJsZAV112nQWlAKw65wMQhE4fir nb5dkjEivBjsv7LgtcBq0kSvEWdVnvQxCEKAx3nBB+ByM9ZUUtJyt6ML6yOhoSGYBhDH zfCcD28QoD18jggyXJFcdUrVdbUdjFbdprl/yV5UOHGjNQNxfjRGSYoS32QmtvnFxXH5 osRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ObijjNNRXE6itlkJdDnoMy05ulET3J5ksrjco4dQA1c=; b=tn0+C0i6zGNHv4eDY6S4O5433lozRgyYCtF93EQfnzYkTB+B6eCpz2qoUI0i6YhXeU fjnL3iuSl5paGLdFhXHtK4xrY+j+8WrDrl9oBlqLmIZ1+cril/4HUKsgB7ukqnISK/Jh YwjZzHWfAm8uAz1gcoAITRssGrhcv6YvaucX8k49TSDjusHHWTYdtS7PDTnsI+sm9+Pd n3WnYPvcHRdIpB3f7wBRd9Hg3zsroye2tRgntvMPgFjOrFnKPnLgzhHS+L3SJ3vtJpTC V6FWTiq+4j95iO6ff7nz4zayxOeYPGOHSRkZ0QEfp5vRYucv+G2wVjF/0yYJsRlq0ry6 5VZg== X-Gm-Message-State: AOAM531XPH7lS0DwZuPahnl9Pn0zId2wBqs5fQrgbFV5Z9KYB8KN9NcK g9Dhs/G2MHVCQN0y9de2zlPR7hP8KIAIzUaWj7Zj2Q== X-Google-Smtp-Source: ABdhPJyhT32Rl+FOG0Vq4c2ude2auGlMTF31Nm+vwlDbCHQKWKZwUHRiHKNcqkJrleiFZPHODWHThMKl7Q7TNAB9Bmc= X-Received: by 2002:a05:651c:a12:: with SMTP id k18mr38470379ljq.251.1638812108454; Mon, 06 Dec 2021 09:35:08 -0800 (PST) MIME-Version: 1.0 References: <20211123210109.1605642-1-oupton@google.com> <20211123210109.1605642-5-oupton@google.com> <87r1azm4j1.wl-maz@kernel.org> In-Reply-To: <87r1azm4j1.wl-maz@kernel.org> From: Oliver Upton Date: Mon, 6 Dec 2021 11:34:57 -0600 Message-ID: Subject: Re: [PATCH v3 4/6] KVM: arm64: Emulate the OS Lock To: Marc Zyngier 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211206_093513_872320_19BE500A X-CRM114-Status: GOOD ( 33.60 ) 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 Hey Marc, Apologies for my delay in getting back to you, I was OOO for a while. On Mon, Nov 29, 2021 at 8:16 AM Marc Zyngier wrote: > > 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... Right, this comment in the commit message is stale. In the previous iteration I had done this, but removed it per your suggestion. I'll fix the msg in the next round. > > > > 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. Ack to here and the above comment. Thanks for the review! -- Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel