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=-9.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 B3779C433E0 for ; Fri, 5 Feb 2021 14:05:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 5097C64FC4 for ; Fri, 5 Feb 2021 14:05:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5097C64FC4 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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BRvv/Dfw94eMec0hxrQdAUQ4Li9dGTZCew8GDTRSxTg=; b=QbX0MxH2DHX7OBB4MWCsnQD/E YxoWNzfbASDB6imfrrKEAPFYM5Z4NH+k9tLG73cM6InCtdwMnnB9VnMNC1dbtFlpLdRBjJ7h+KFSX Eh+AOJjagKty+cRpk8YXyVb1WwDl6gRZDFoaIlT1To2KETO9zOiMaPVrZMX7+gOM7juDEmUDbSD/h iip3duQbo/N+TQbG0z+FCKpyV3snkGOo5AzevH3n3Wxh4kZKOfyGr6JGrwJF+4aNp6mhABb07+VPS oUkigQq4AYVl6kEppRm6C8vP6wCgoCnAvn0TdUGo9cMIGoGc26WI/6Cb8h3lwFFJHj9sXdmCKd8gQ 5s2wdrjSg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l81it-0000Br-0T; Fri, 05 Feb 2021 14:04:35 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l81iq-0000B0-4c for linux-arm-kernel@lists.infradead.org; Fri, 05 Feb 2021 14:04:33 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 37A8D64FCB; Fri, 5 Feb 2021 14:04:31 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1l81in-00CHIk-17; Fri, 05 Feb 2021 14:04:29 +0000 MIME-Version: 1.0 Date: Fri, 05 Feb 2021 14:04:28 +0000 From: Marc Zyngier To: Hector Martin 'marcan' Subject: Re: [PATCH v6 05/21] arm64: Initialise as nVHE before switching to VHE In-Reply-To: <1dbffcd4-5b20-404c-94af-c985a96785e2@marcan.st> References: <20210201115637.3123740-1-maz@kernel.org> <20210201115637.3123740-6-maz@kernel.org> <1dbffcd4-5b20-404c-94af-c985a96785e2@marcan.st> User-Agent: Roundcube Webmail/1.4.10 Message-ID: <2f93bbfa7159f135252c6df870a652cc@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: marcan@marcan.st, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, mark.rutland@arm.com, jingzhangos@google.com, psodagud@codeaurora.org, sramana@codeaurora.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, alexandru.elisei@arm.com, james.morse@arm.com, pajay@qti.qualcomm.com, kernel-team@android.com, dbrazdil@google.com, will@kernel.org, ardb@kernel.org, julien.thierry.kdev@gmail.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-20210205_090432_374766_3FEB4C92 X-CRM114-Status: GOOD ( 20.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Jing Zhang , kernel-team@android.com, Srinivas Ramana , Suzuki K Poulose , Catalin Marinas , linux-kernel@vger.kernel.org, Ard Biesheuvel , David Brazdil , Will Deacon , James Morse , Julien Thierry , Ajay Patil , Prasad Sodagudi , Alexandru Elisei , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Hector, On 2021-02-05 12:01, Hector Martin 'marcan' wrote: > On 01/02/2021 20.56, Marc Zyngier wrote: >> As we are aiming to be able to control whether we enable VHE or >> not, let's always drop down to EL1 first, and only then upgrade >> to VHE if at all possible. >> >> This means that if the kernel is booted at EL2, we always start >> with a nVHE init, drop to EL1 to initialise the the kernel, and >> only then upgrade the kernel EL to EL2 if possible (the process >> is obviously shortened for secondary CPUs). > > Unfortunately, this is going to break on Apple SoCs, where it turns > out HCR_EL2.E2H is hard-wired to 1 - there is no nVHE mode. :( #facepalm Thanks for the heads up. That's a blatant violation of the architecture, as the only fixed value allowed is 0. I guess it was tempting for them to ignore about half of the architecture... Oh well. Here's a terrible hack on top of this series. It really doesn't play nicely with the rest of the override stuff, but that's the least of your worries at this stage. I've boot-tested it in a model with E2H artificially forced, and nothing caught fire. YMMV. It also means that if/when we merge the support for this CPU, CONFIG_ARM64_VHE will becomes more or less mandatory... Please let me know if this helps. Thanks, M. diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 2e116ef255e1..bce66d6bda74 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 3e08dcc924b5..109a555a1068 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) @@ -227,3 +227,24 @@ 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 + ldr x0, [x1] + bic x0, x0, #(0xf << ID_AA64MMFR1_VHE_SHIFT) + str x0, [x1] + + mov x0, #HVC_VHE_RESTART + hvc #0 + mov x0, #BOOT_CPU_MODE_EL2 + ret +SYM_FUNC_END(stick_to_vhe) + -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel