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 3C17BC52D7B for ; Tue, 13 Aug 2024 17:14:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1l/F5SkMqgFiC+97cuRkAHI6rn0cPRKe+Kq6ZOOmDdY=; b=q6vTwuj9z8rQM76YQXX6bHCe5z rAu3PDFP01oyOKMro3eQXaPrveTx5tVzjjipLK6LNiOvSKU0lFt2nU30zVuusJwZViRr343d7h0NH VEnO0ZHc5pWyIkU0XBv1jW9EEhev9vIfYja7IU46OuHVrUKox/eCLSYn6d9hDl57p1sFJgvOFQiS4 ll2LNsE+HH5H91A289YUAXiPDeF4o8dARxBL47wTZBf2t0f8xspR5DKmo/9fL5Dlh6l1LlzGAXPRP qcWfA+x1vkSAMvK7zzlEya4EVnMDkuNTefPgjLcJaGql8Jz27CbBbzwvDMqyHY8a5eOfurUBmUV4G QyKNszJA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdv6S-00000004Tv5-2tp0; Tue, 13 Aug 2024 17:14:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdv5q-00000004Trr-1HXo for linux-arm-kernel@lists.infradead.org; Tue, 13 Aug 2024 17:13:59 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B4B11FEC; Tue, 13 Aug 2024 10:14:20 -0700 (PDT) Received: from donnerap.manchester.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 002503F58B; Tue, 13 Aug 2024 10:13:53 -0700 (PDT) Date: Tue, 13 Aug 2024 18:13:51 +0100 From: Andre Przywara To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, akos.denke@arm.com, luca.fancellu@arm.com, maz@kernel.org Subject: Re: [BOOT-WRAPPER v2 02/10] aarch64: Implement cpu_init_arch() Message-ID: <20240813181351.5ffb1756@donnerap.manchester.arm.com> In-Reply-To: <20240812101555.3558589-3-mark.rutland@arm.com> References: <20240812101555.3558589-1-mark.rutland@arm.com> <20240812101555.3558589-3-mark.rutland@arm.com> Organization: ARM X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240813_101358_422323_958372FC X-CRM114-Status: GOOD ( 24.71 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 12 Aug 2024 11:15:47 +0100 Mark Rutland wrote: > When the boot-wrapper is entered at EL2 it does not initialise > CNTFRQ_EL0, and in future it may need to initialize other CPU state > regardless of the exeption level it was entered at. > > Use a common cpu_init_arch() function to initialize CPU state regardless > of the exception level the boot-wrapper was entered at. > > This change means that the boot-wrapper can only be used when enetered > at the highest implemented exception level, as accesses to CNTFRQ_EL0 > will be UNDEFINED at lower exception levels. However, the boot-wrapper > only supports being booted at the highest implemented exception level, > as the comment at the top of boot.S describes: > > | The boot-wrapper must be entered from the reset vector at the > | highest implemented exception level. > > ... so this should not adversely affect any supported configuration. Yes, makes sense, and fixes the panic from the kernel when entered in EL2, where it cannot determine the arch timer frequency: Reviewed-by: Andre Przywara Cheers, Andre > > Signed-off-by: Mark Rutland > Acked-by: Marc Zyngier > Cc: Akos Denke > Cc: Andre Przywara > Cc: Luca Fancellu > --- > arch/aarch64/boot.S | 4 +++- > arch/aarch64/init.c | 12 +++++++++--- > 2 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S > index 73ddcd0..52c617d 100644 > --- a/arch/aarch64/boot.S > +++ b/arch/aarch64/boot.S > @@ -51,7 +51,7 @@ reset_at_el3: > > bl cpu_init_bootwrapper > > - bl cpu_init_el3 > + bl cpu_init_arch > > bl gic_secure_init > > @@ -82,6 +82,8 @@ reset_at_el2: > > bl cpu_init_bootwrapper > > + bl cpu_init_arch > + > b start_bootmethod > > err_invalid_id: > diff --git a/arch/aarch64/init.c b/arch/aarch64/init.c > index c9fc7f1..49abdf7 100644 > --- a/arch/aarch64/init.c > +++ b/arch/aarch64/init.c > @@ -52,7 +52,7 @@ static inline bool cpu_has_permission_indirection(void) > return mrs(ID_AA64MMFR3_EL1) & mask; > } > > -void cpu_init_el3(void) > +static void cpu_init_el3(void) > { > unsigned long scr = SCR_EL3_RES1 | SCR_EL3_NS | SCR_EL3_HCE; > unsigned long mdcr = 0; > @@ -153,8 +153,6 @@ void cpu_init_el3(void) > > msr(SMCR_EL3, smcr); > } > - > - msr(CNTFRQ_EL0, COUNTER_FREQ); > } > > #ifdef PSCI > @@ -171,3 +169,11 @@ bool cpu_init_psci_arch(void) > return true; > } > #endif > + > +void cpu_init_arch(void) > +{ > + if (mrs(CurrentEL) == CURRENTEL_EL3) > + cpu_init_el3(); > + > + msr(CNTFRQ_EL0, COUNTER_FREQ); > +}