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 6E44CC63684 for ; Wed, 26 Jan 2022 15:22:13 +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: 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=hBogOWntVnRtI99xEpxA4n8xFImcHOijcH3Ass4K0e8=; b=gz8M/dVELJ9KGL 39lqULWG6RIrXCoIcixuC9TRGFW4astnZFbm8MnJJbfBvGZAXp7hKzFCQ2CnKve5ZLeKgndjetZm+ bRuUUQWz9XFXF+UT4U+i/Jp64qSYREyWLG7SzDnWVKXqk1EBCeThKn2UZHqYbcl7+Hf7+lX/HCBr5 MrWWTkvuv6q47yasIegWSgYJb5vaYOBpZSsBg+gXf4HmUi+Z4a3uSwqghbOTsTK/80PptHRA/NFtW jzs8PrkBZVWMwoOa08/NcnSMt1el17Lji4bhAZw8yQtGZ8pDpctdRKNpb1gUiODzGwrcgoOiUH9yZ ovpcGXaEoSEpZMp1iAwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCk6M-00CEkT-6G; Wed, 26 Jan 2022 15:20:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCjpx-00C6vK-P3 for linux-arm-kernel@lists.infradead.org; Wed, 26 Jan 2022 15:03:55 +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 E87631FB; Wed, 26 Jan 2022 07:03:52 -0800 (PST) Received: from donnerap.cambridge.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 DE2633F793; Wed, 26 Jan 2022 07:03:51 -0800 (PST) Date: Wed, 26 Jan 2022 15:03:49 +0000 From: Andre Przywara To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org, jaxson.han@arm.com, robin.murphy@arm.com, vladimir.murzin@arm.com, wei.chen@arm.com Subject: Re: [bootwrapper PATCH v3 03/15] Document entry requirements Message-ID: <20220126150349.68186b6b@donnerap.cambridge.arm.com> In-Reply-To: <20220125150057.3936090-4-mark.rutland@arm.com> References: <20220125150057.3936090-1-mark.rutland@arm.com> <20220125150057.3936090-4-mark.rutland@arm.com> Organization: ARM X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220126_070353_977566_053EB217 X-CRM114-Status: GOOD ( 29.70 ) 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, 25 Jan 2022 15:00:45 +0000 Mark Rutland wrote: Hi, > Currently the boot-wrapper only supports some combinations of exception > levels, with other combinations not being supported. > > While we generally expect the boot-wrapper to be entered at the highest > implemented exception level, the AArch32 boot-wrapper has a comment > implying it supports being entered with something else owning EL3. As > this would require such EL3 firmware to always be in sync with the > boot-wrapper's requirements, which change over time, we don't actually > support such a configuration. > > Some CPU state (such as CNTFRQ/CNTFRQ_EL0) needs to be initialized at > the highest implemented exception level, but today the boot-wrapper only > does so when entered at EL3 / Secure-PL1. Thus, today the only > completely supported configurations are EL3 / Secure-PL1, and entering > in other configurations is not entirely supported. > > The aarch64 `jump_kernel` function always writes to SCTLR_EL2, which is > UNDEFINED at EL1. Hence, the aarch64 boot-wrapper does not support being > entered at EL1. > > The aarch32 code assumes that any non-hyp mode is Secure PL1, and > attempt to switch to monitor mode. If entered on a system without the > security extensions, where the highest privileged mode is Non-secure > PL1, this will not work. Hence the aarch32 boot-wrapper does not support > being entered at Non-secure PL1. > > Actually supporting all of these configurations requires restructuring > much of the boot-wrapper. For now, document the supported configurations > in each architecture's boot.S, and remove the misleading comment from > arch/aarch32/boot.S. Subsequent patches will improve the support and add > support for additional configurations. > > There should be no functional change as a result of this patch. > > Signed-off-by: Mark Rutland I like that idea of documenting what we can sanely support, instead of trying to support everyone and their dog, when this won't work in practice anyway or cannot be well tested. Reviewed-by: Andre Przywara Thanks! Andre > --- > arch/aarch32/boot.S | 14 ++++++++++++++ > arch/aarch32/psci.S | 5 ----- > arch/aarch64/boot.S | 13 +++++++++++++ > 3 files changed, 27 insertions(+), 5 deletions(-) > > diff --git a/arch/aarch32/boot.S b/arch/aarch32/boot.S > index 4add338..00c432d 100644 > --- a/arch/aarch32/boot.S > +++ b/arch/aarch32/boot.S > @@ -16,6 +16,20 @@ > .arch_extension virt > > .section .init > + > + /* > + * The boot-wrapper must be entered from the reset vector at the > + * highest implemented exception level. The boot-wrapper only supports > + * being entered in the following modes: > + * > + * - PL1 / EL3 (Secure) Supervisor mode > + * Entering in this mode is strongly recommended. > + * PL2 must be implemented. > + * > + * - PL2 / EL2 (Non-secure) Hypervisor mode > + * Entering in this mode is partially supported. > + * PSCI is not supported when entered in this mode. > + */ > ASM_FUNC(_start) > /* Stack initialisation */ > cpuid r0, r1 > diff --git a/arch/aarch32/psci.S b/arch/aarch32/psci.S > index dc7aeb7..e0d2972 100644 > --- a/arch/aarch32/psci.S > +++ b/arch/aarch32/psci.S > @@ -44,11 +44,6 @@ ASM_FUNC(start_el3) > /* pass through */ > > ASM_FUNC(start_no_el3) > - /* > - * For no-el3, we assume that firmware launched the boot-wrapper in > - * non-secure EL2 or EL1. We assume it has its own PSCI implementation > - * sitting at EL3, and that this path is only taken by primary CPU. > - */ > cpuid r0, r1 > blx find_logical_id > b psci_first_spin > diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S > index ee9ddaa..d682ba5 100644 > --- a/arch/aarch64/boot.S > +++ b/arch/aarch64/boot.S > @@ -12,6 +12,19 @@ > > .section .init > > + /* > + * The boot-wrapper must be entered from the reset vector at the > + * highest implemented exception level. The boot-wrapper only supports > + * being entered at the following exception levels: > + * > + * - EL3 (Secure) > + * Entering at EL3 is strongly recommended. > + * EL2 must be implemented. > + * > + * - EL2 (Non-secure) > + * Entering at EL2 is partially supported. > + * PSCI is not supported when entered in this exception level. > + */ > ASM_FUNC(_start) > cpuid x0, x1 > bl find_logical_id _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel