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 X-Spam-Level: X-Spam-Status: No, score=-17.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11550C433E3 for ; Wed, 24 Mar 2021 18:06:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C3D9361A1F for ; Wed, 24 Mar 2021 18:06:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237364AbhCXSGW (ORCPT ); Wed, 24 Mar 2021 14:06:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:37408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232618AbhCXSFy (ORCPT ); Wed, 24 Mar 2021 14:05:54 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4430861A1B; Wed, 24 Mar 2021 18:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616609154; bh=4ddFWD0HDeMvJooIHBmVBLMfgHrZIiewXKZt5ch7iWs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A6FHmx+M+t/r7327J8jHlQn2j7eeeQwtuRXHcULuzLaaVTXqZuHY/wFrucrpfDQZC takEBJ1G9jXLsxWNCfiPyc5ZsXKzT28qWT72jH7fC40YsYIR6fwCVeQCoVV2TtWmRK LS4MrPVDMZakskpDgdmzRuOpYyqqXPbmznxYMSyIwiDu9rGOlBQrm7O3NetB/A0p/w bo3i8Dzo1959a2p8UE2xQyE/NJhKDQ5hgIwCiTXFbJtvuzmT5chNnES9MbrJQ9BnGx jqlnKGaoqZzmXDfV9VMH5xlIPe9OzrVIVBpaKUO3ToguDiPbUNN04mlRNBY/WbP8/S iEWD9+cmga8Tw== Date: Wed, 24 Mar 2021 18:05:46 +0000 From: Will Deacon To: Hector Martin Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Rob Herring , Arnd Bergmann , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFT PATCH v3 01/27] arm64: Cope with CPUs stuck in VHE mode Message-ID: <20210324180546.GA13181@willie-the-truck> References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-2-marcan@marcan.st> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210304213902.83903-2-marcan@marcan.st> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 05, 2021 at 06:38:36AM +0900, Hector Martin wrote: > From: Marc Zyngier > > It seems that the CPU known as Apple M1 has the terrible habit > of being stuck with HCR_EL2.E2H==1, in violation of the architecture. > > Try and work around this deplorable state of affairs by detecting > the stuck bit early and short-circuit the nVHE dance. It is still > unknown whether there are many more such nuggets to be found... > > Reported-by: Hector Martin > Signed-off-by: Marc Zyngier > --- > arch/arm64/kernel/head.S | 33 ++++++++++++++++++++++++++++++--- > arch/arm64/kernel/hyp-stub.S | 28 ++++++++++++++++++++++++---- > 2 files changed, 54 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index 66b0e0b66e31..673002b11865 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -477,14 +477,13 @@ EXPORT_SYMBOL(kimage_vaddr) > * booted in EL1 or EL2 respectively. > */ > SYM_FUNC_START(init_kernel_el) > - mov_q x0, INIT_SCTLR_EL1_MMU_OFF > - msr sctlr_el1, x0 > - > mrs x0, CurrentEL > cmp x0, #CurrentEL_EL2 > b.eq init_el2 > > SYM_INNER_LABEL(init_el1, SYM_L_LOCAL) > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > + msr sctlr_el1, x0 > isb > mov_q x0, INIT_PSTATE_EL1 > msr spsr_el1, x0 > @@ -504,6 +503,34 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL) > msr vbar_el2, x0 > isb > > + /* > + * Fruity CPUs seem to have HCR_EL2.E2H set to RES1, > + * making it impossible to start in nVHE mode. Is that > + * compliant with the architecture? Absolutely not! > + */ > + mrs x0, hcr_el2 > + and x0, x0, #HCR_E2H > + cbz x0, 1f > + > + /* Switching to VHE requires a sane SCTLR_EL1 as a start */ > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > + msr_s SYS_SCTLR_EL12, x0 > + > + /* > + * Force an eret into a helper "function", and let it return > + * to our original caller... This makes sure that we have > + * initialised the basic PSTATE state. > + */ > + mov x0, #INIT_PSTATE_EL2 > + msr spsr_el1, x0 > + adr_l x0, stick_to_vhe > + msr elr_el1, x0 > + eret > + > +1: > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > + msr sctlr_el1, x0 > + > msr elr_el2, lr > mov w0, #BOOT_CPU_MODE_EL2 > eret > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S > index 5eccbd62fec8..c7601030ee82 100644 > --- a/arch/arm64/kernel/hyp-stub.S > +++ b/arch/arm64/kernel/hyp-stub.S > @@ -27,12 +27,12 @@ SYM_CODE_START(__hyp_stub_vectors) > ventry el2_fiq_invalid // FIQ EL2t > ventry el2_error_invalid // Error EL2t > > - ventry el2_sync_invalid // Synchronous EL2h > + ventry elx_sync // Synchronous EL2h > ventry el2_irq_invalid // IRQ EL2h > ventry el2_fiq_invalid // FIQ EL2h > ventry el2_error_invalid // Error EL2h > > - ventry el1_sync // Synchronous 64-bit EL1 > + ventry elx_sync // Synchronous 64-bit EL1 > ventry el1_irq_invalid // IRQ 64-bit EL1 > ventry el1_fiq_invalid // FIQ 64-bit EL1 > ventry el1_error_invalid // Error 64-bit EL1 > @@ -45,7 +45,7 @@ SYM_CODE_END(__hyp_stub_vectors) > > .align 11 > > -SYM_CODE_START_LOCAL(el1_sync) > +SYM_CODE_START_LOCAL(elx_sync) > cmp x0, #HVC_SET_VECTORS > b.ne 1f > msr vbar_el2, x1 > @@ -71,7 +71,7 @@ SYM_CODE_START_LOCAL(el1_sync) > > 9: mov x0, xzr > eret > -SYM_CODE_END(el1_sync) > +SYM_CODE_END(elx_sync) > > // nVHE? No way! Give me the real thing! > SYM_CODE_START_LOCAL(mutate_to_vhe) > @@ -243,3 +243,23 @@ SYM_FUNC_START(switch_to_vhe) > #endif > ret > SYM_FUNC_END(switch_to_vhe) > + > +SYM_FUNC_START(stick_to_vhe) > + /* > + * Make sure the switch to VHE cannot fail, by overriding the > + * override. This is hilarious. > + */ > + adr_l x1, id_aa64mmfr1_override > + add x1, x1, #FTR_OVR_MASK_OFFSET > + dc civac, x1 > + dsb sy > + isb Why do we need an ISB here? > + ldr x0, [x1] > + bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) > + str x0, [x1] I find it a bit bizarre doing this here, as for the primary CPU we're still a way away from parsing the early paramaters and for secondary CPUs this doesn't need to be done for each one. Furthermore, this same code is run on the resume path, which can probably then race with itself. Is it possible to do it later on the boot CPU only, e.g. in init_feature_override()? We should probably also log a warning that we're ignoring the option because nVHE is not available. Will 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 X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69EF3C433C1 for ; Wed, 24 Mar 2021 18:07:48 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F3C4261A21 for ; Wed, 24 Mar 2021 18:07:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3C4261A21 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: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=NGfXd9dYUmnXnQtEpOvzMHGvf98rkdbLQqpXAm0IJ3M=; b=WwPnYIocMjr/qThmXusrmis/L S0HYMl/lh0IGI7hXmFkkTzQwdGPH5AO9+ukY8pS46uzd4rkp133ATLVfVGFm7u2+5m8MQEESLYkKc c4TZOlDrioRPI220GFOhquGBEZxxblIUbYTqOG96UEAniGdQPU6wfv8nbe9KWKxkEpplLjRWAFCTV JEJWV6cgxL0QploxM7acbx8Ab5PGxhRQAD7QPdF+teCIhCghDVk3wOcRMbnLa8SyEoEei7XZfK8w0 3T3aLnCeeB10GouGKeJRrPwjvk2gLyKubTXz1Tq6Zst6ALcmvXPYVMTpkwGkOAsY+S2DObK7omLs1 1IXL5NHNA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lP7tK-0000tA-9u; Wed, 24 Mar 2021 18:06:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lP7tD-0000sZ-Un for linux-arm-kernel@lists.infradead.org; Wed, 24 Mar 2021 18:05:58 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4430861A1B; Wed, 24 Mar 2021 18:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616609154; bh=4ddFWD0HDeMvJooIHBmVBLMfgHrZIiewXKZt5ch7iWs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A6FHmx+M+t/r7327J8jHlQn2j7eeeQwtuRXHcULuzLaaVTXqZuHY/wFrucrpfDQZC takEBJ1G9jXLsxWNCfiPyc5ZsXKzT28qWT72jH7fC40YsYIR6fwCVeQCoVV2TtWmRK LS4MrPVDMZakskpDgdmzRuOpYyqqXPbmznxYMSyIwiDu9rGOlBQrm7O3NetB/A0p/w bo3i8Dzo1959a2p8UE2xQyE/NJhKDQ5hgIwCiTXFbJtvuzmT5chNnES9MbrJQ9BnGx jqlnKGaoqZzmXDfV9VMH5xlIPe9OzrVIVBpaKUO3ToguDiPbUNN04mlRNBY/WbP8/S iEWD9+cmga8Tw== Date: Wed, 24 Mar 2021 18:05:46 +0000 From: Will Deacon To: Hector Martin Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Rob Herring , Arnd Bergmann , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFT PATCH v3 01/27] arm64: Cope with CPUs stuck in VHE mode Message-ID: <20210324180546.GA13181@willie-the-truck> References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-2-marcan@marcan.st> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210304213902.83903-2-marcan@marcan.st> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210324_180556_575403_57AD010E X-CRM114-Status: GOOD ( 29.46 ) 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 Fri, Mar 05, 2021 at 06:38:36AM +0900, Hector Martin wrote: > From: Marc Zyngier > > It seems that the CPU known as Apple M1 has the terrible habit > of being stuck with HCR_EL2.E2H==1, in violation of the architecture. > > Try and work around this deplorable state of affairs by detecting > the stuck bit early and short-circuit the nVHE dance. It is still > unknown whether there are many more such nuggets to be found... > > Reported-by: Hector Martin > Signed-off-by: Marc Zyngier > --- > arch/arm64/kernel/head.S | 33 ++++++++++++++++++++++++++++++--- > arch/arm64/kernel/hyp-stub.S | 28 ++++++++++++++++++++++++---- > 2 files changed, 54 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index 66b0e0b66e31..673002b11865 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -477,14 +477,13 @@ EXPORT_SYMBOL(kimage_vaddr) > * booted in EL1 or EL2 respectively. > */ > SYM_FUNC_START(init_kernel_el) > - mov_q x0, INIT_SCTLR_EL1_MMU_OFF > - msr sctlr_el1, x0 > - > mrs x0, CurrentEL > cmp x0, #CurrentEL_EL2 > b.eq init_el2 > > SYM_INNER_LABEL(init_el1, SYM_L_LOCAL) > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > + msr sctlr_el1, x0 > isb > mov_q x0, INIT_PSTATE_EL1 > msr spsr_el1, x0 > @@ -504,6 +503,34 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL) > msr vbar_el2, x0 > isb > > + /* > + * Fruity CPUs seem to have HCR_EL2.E2H set to RES1, > + * making it impossible to start in nVHE mode. Is that > + * compliant with the architecture? Absolutely not! > + */ > + mrs x0, hcr_el2 > + and x0, x0, #HCR_E2H > + cbz x0, 1f > + > + /* Switching to VHE requires a sane SCTLR_EL1 as a start */ > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > + msr_s SYS_SCTLR_EL12, x0 > + > + /* > + * Force an eret into a helper "function", and let it return > + * to our original caller... This makes sure that we have > + * initialised the basic PSTATE state. > + */ > + mov x0, #INIT_PSTATE_EL2 > + msr spsr_el1, x0 > + adr_l x0, stick_to_vhe > + msr elr_el1, x0 > + eret > + > +1: > + mov_q x0, INIT_SCTLR_EL1_MMU_OFF > + msr sctlr_el1, x0 > + > msr elr_el2, lr > mov w0, #BOOT_CPU_MODE_EL2 > eret > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S > index 5eccbd62fec8..c7601030ee82 100644 > --- a/arch/arm64/kernel/hyp-stub.S > +++ b/arch/arm64/kernel/hyp-stub.S > @@ -27,12 +27,12 @@ SYM_CODE_START(__hyp_stub_vectors) > ventry el2_fiq_invalid // FIQ EL2t > ventry el2_error_invalid // Error EL2t > > - ventry el2_sync_invalid // Synchronous EL2h > + ventry elx_sync // Synchronous EL2h > ventry el2_irq_invalid // IRQ EL2h > ventry el2_fiq_invalid // FIQ EL2h > ventry el2_error_invalid // Error EL2h > > - ventry el1_sync // Synchronous 64-bit EL1 > + ventry elx_sync // Synchronous 64-bit EL1 > ventry el1_irq_invalid // IRQ 64-bit EL1 > ventry el1_fiq_invalid // FIQ 64-bit EL1 > ventry el1_error_invalid // Error 64-bit EL1 > @@ -45,7 +45,7 @@ SYM_CODE_END(__hyp_stub_vectors) > > .align 11 > > -SYM_CODE_START_LOCAL(el1_sync) > +SYM_CODE_START_LOCAL(elx_sync) > cmp x0, #HVC_SET_VECTORS > b.ne 1f > msr vbar_el2, x1 > @@ -71,7 +71,7 @@ SYM_CODE_START_LOCAL(el1_sync) > > 9: mov x0, xzr > eret > -SYM_CODE_END(el1_sync) > +SYM_CODE_END(elx_sync) > > // nVHE? No way! Give me the real thing! > SYM_CODE_START_LOCAL(mutate_to_vhe) > @@ -243,3 +243,23 @@ SYM_FUNC_START(switch_to_vhe) > #endif > ret > SYM_FUNC_END(switch_to_vhe) > + > +SYM_FUNC_START(stick_to_vhe) > + /* > + * Make sure the switch to VHE cannot fail, by overriding the > + * override. This is hilarious. > + */ > + adr_l x1, id_aa64mmfr1_override > + add x1, x1, #FTR_OVR_MASK_OFFSET > + dc civac, x1 > + dsb sy > + isb Why do we need an ISB here? > + ldr x0, [x1] > + bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) > + str x0, [x1] I find it a bit bizarre doing this here, as for the primary CPU we're still a way away from parsing the early paramaters and for secondary CPUs this doesn't need to be done for each one. Furthermore, this same code is run on the resume path, which can probably then race with itself. Is it possible to do it later on the boot CPU only, e.g. in init_feature_override()? We should probably also log a warning that we're ignoring the option because nVHE is not available. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel