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 9AEE7C25B74 for ; Tue, 21 May 2024 21:09:04 +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=SApE4hFu0eZ4p0qGUqbsIYe7r+0G2rNy/cSCiHW3rMQ=; b=HSnpBeEFfx/WXL CF/MVrDx0n+PIlOmC5dNyZDLqMychv148D3Myow34v1VLhFmzLTGGdR1El1M2KBaIksFi87n8ilUe c6CRIbSRbP9dp2IeMEMfGzRTe/lfRqfLMvc0CCrOX7T1jPc12EfYabJKYl/1inhFyCDIiN973Jqob 9iNA8anXfHgbsJpPoBVKNtOQGU7j1sM+jDaTGiwtS8GsgcWGhGjWwPfrCxr56hVJPfs+jeWQa3IKN MzUpqnuv2dGxVCbcUUJYc2TU9gfPaLfzRlMAHxVQgI9Hp+laItI8dm3nXU0e3jCNyplLHWv1m/Iu+ nZcK9q+oemIT1eK4tcZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9Wj9-000000015uZ-02NG; Tue, 21 May 2024 21:08:55 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9Wj5-000000015u2-2o3D for linux-arm-kernel@lists.infradead.org; Tue, 21 May 2024 21:08:53 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B4BF062448; Tue, 21 May 2024 21:08:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AF8FC2BD11; Tue, 21 May 2024 21:08:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716325730; bh=Q6+t4Wag+AbwutnQpFC+4WXVks6pqEcCpIp21PwqiUU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=D43alZzvGYPwZoSkfntRkCe/KpgdTG41rxSb44HDLM9XPR5LCswfG56y1EeGAEOhN AKwi11HCM3lwB9JG9cubkFGaHSEyJ2YYL88PQIXTKUTP/yZwGcud5ojq8R9auTpS70 mbkf9FXg+lPHsL7xvHmYm0GXfHybQJRp97vcHzY0jcI9tZfc2LjjoLEtE886LoFQMP H9/ICGbnxSYJcbEn9U5EmBinqYHmZtpWQGKUOxdWx9i9DyfzMGXHEVMoSXwrTbjyNb k/Hfw3+x2N+nj7NYExgBMdfnOtA6xR+IPGEPukmvKzalDtJvtMdgbK6Ji/wiJwkW/j u4Wa8LLVPdrXA== 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 1s9Wj1-00Enoa-EH; Tue, 21 May 2024 22:08:47 +0100 Date: Tue, 21 May 2024 22:08:46 +0100 Message-ID: <86seyana8x.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.com Subject: Re: [PATCH v2 2/7] KVM: arm64: Abstract set/clear of CPTR_EL2 bits behind helper In-Reply-To: <20240521163720.3812851-3-tabba@google.com> References: <20240521163720.3812851-1-tabba@google.com> <20240521163720.3812851-3-tabba@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/29.2 (aarch64-unknown-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: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.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-20240521_140851_835357_4880DE6E X-CRM114-Status: GOOD ( 25.21 ) 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, 21 May 2024 17:37:15 +0100, Fuad Tabba wrote: > > The same traps controlled by CPTR_EL2 or CPACR_EL1 need to be > toggled in different parts of the code, but the exact bits and > their polarity differ between these two formats and the mode > (vhe/nvhe/hvhe). > > To reduce the amount of duplicated code and the chance of getting > the wrong bit/polarity or missing a field, abstract the set/clear > of CPTR_EL2 bits behind a helper. > > Since (h)VHE is the way of the future, use the CPACR_EL1 format, > which is a subset of the VHE CPTR_EL2, as a reference. > > No functional change intended. > > Suggested-by: Oliver Upton > Signed-off-by: Fuad Tabba > --- > arch/arm64/include/asm/kvm_emulate.h | 34 +++++++++++++++++++++++++ > arch/arm64/kvm/hyp/include/hyp/switch.h | 17 +++---------- > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 +---- > 3 files changed, 39 insertions(+), 18 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h > index 501e3e019c93..74837d1762e5 100644 > --- a/arch/arm64/include/asm/kvm_emulate.h > +++ b/arch/arm64/include/asm/kvm_emulate.h > @@ -557,6 +557,40 @@ static __always_inline void kvm_incr_pc(struct kvm_vcpu *vcpu) > vcpu_set_flag((v), e); \ > } while (0) > > + > +static inline void __cptr_clear_set_nvhe(u64 cpacr_clr, u64 cpacr_set) > +{ > + u64 clr = 0, set = 0; > + > + if (cpacr_clr & CPACR_ELx_FPEN) > + set |= CPTR_EL2_TFP; > + if (cpacr_clr & CPACR_ELx_ZEN) > + set |= CPTR_EL2_TZ; > + if (cpacr_clr & CPACR_ELx_SMEN) These 3 fields are actually pairs of bits. Can we have a compile-time check that both bits are set? > + set |= CPTR_EL2_TSM; > + if (cpacr_clr & CPACR_ELx_TTA) > + clr |= CPTR_EL2_TTA; How about TCPAC, TAM, and E0POE? > + > + if (cpacr_set & CPACR_ELx_FPEN) > + clr |= CPTR_EL2_TFP; > + if (cpacr_set & CPACR_ELx_ZEN) > + clr |= CPTR_EL2_TZ; > + if (cpacr_set & CPACR_ELx_SMEN) > + clr |= CPTR_EL2_TSM; > + if (cpacr_set & CPACR_ELx_TTA) > + set |= CPTR_EL2_TTA; The duplication is pretty unfortunate. Having a single helper that translate a register layout into another would be better. > + > + sysreg_clear_set(cptr_el2, clr, set); And omit this... > +} > + > +static inline void cpacr_clear_set(u64 clr, u64 set) > +{ > + if (has_vhe() || has_hvhe()) > + sysreg_clear_set(cpacr_el1, clr, set); > + else > + __cptr_clear_set_nvhe(clr, set); So that this could read as: sysreg_clear_set(cptr_el2, cpacr_to_cptr(clr), cpacr_to_cptr(set)); 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