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=-20.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 9AF43C4338F for ; Fri, 23 Jul 2021 16:50:20 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 6B02B60E78 for ; Fri, 23 Jul 2021 16:50:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6B02B60E78 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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: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=cm/71Jlqt5PfPxES5criDwStSPusFhg1uK0G9xJWy9o=; b=kduOfGVbbq9NOc UEQOOYB/KGjavB20sx9+IBn2EL9M4tvRzZfw0CxMsKWXRi1MfCpMy2jsUE6oPp34op7uF0k61fc/F bWen7QxEKgd7OowAo3XgVoYtN1jTJvXKjr5UpyRI4CHXxwU2uEbGMjohJMD9j8ho72EDUKS/hdf0g zFl+wpiBSsSFypMJHdrZSTG8FYWf4NtvM3sLdp9HyrP1ckriytD5EQHfh3VKN+AReuT6qPNTlAMGa bQDJdmeBHae/xoubehKVZDW/BZvE7EBCjBVxuZyO3s9UXCyMDoh5e+l4XurEKlkOGoCeF5JRDWjH1 b5lloM+F7j7dsqYJObkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6yM5-005Mff-Dj; Fri, 23 Jul 2021 16:48:57 +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 1m6yM1-005MeW-6x for linux-arm-kernel@lists.infradead.org; Fri, 23 Jul 2021 16:48: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 A65E211D4; Fri, 23 Jul 2021 09:48:47 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.7.143]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A026D3F73D; Fri, 23 Jul 2021 09:48:46 -0700 (PDT) Date: Fri, 23 Jul 2021 17:48:41 +0100 From: Mark Rutland To: Jaxson Han Cc: andre.przywara@arm.com, linux-arm-kernel@lists.infradead.org, wei.chen@arm.com Subject: Re: [boot-wrapper PATCH v3 2/8] aarch64: Rename labels and prepare for lower EL booting Message-ID: <20210723164841.GA48892@C02TD0UTHF1T.local> References: <20210525062509.201464-1-jaxson.han@arm.com> <20210525062509.201464-3-jaxson.han@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210525062509.201464-3-jaxson.han@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210723_094853_400794_74522BDA X-CRM114-Status: GOOD ( 28.83 ) 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, May 25, 2021 at 02:25:03PM +0800, Jaxson Han wrote: > Prepare for booting from lower EL. Rename *_el3 relavant labels with > *_el_max and *_no_el3 with *_keep_el. Since the original _no_el3 means > "We neither do init sequence at this highest EL nor drop to lower EL > when entering to kernel", we rename it with _keep_el to make it more > clear for lower EL initialisation. I think the existing behaviour here where we don't initialize EL2 in the _no_el3 case is an accident rather than a deliberate design decision, and is unsound (e.g. as SCTLR_ELx.EE resets to an IMPLEMENTATION DEFINED value, but we assume it's little-endian). I think we need to clean that up before we alter this further, since the existing code supposedly supports cases that cannot work correctly. I also think that we should mandate that the boot-wrapper is started at the highest implemented exception level. We used to care about being a TF-A payload, but that hasn't been the case since TF-A commit: 32412a8a6b0da74d ("Replace bootwrapped kernel instructions from User Guide") ... and it will be significantly easier to do the right thing if the boot-wrapper is directly in charge of the HW. Does that fit with your use-case? I've started work on that, and I have some WIP patches at: https://git.kernel.org/pub/scm/linux/kernel/git/mark/boot-wrapper-aarch64.git/log/?h=cleanup ... which I'll spend some more time on next week, and I'll have a go at picking up portions of this series atop that. Thanks, Mark. > > Signed-off-by: Jaxson Han > --- > arch/aarch64/boot.S | 31 +++++++++++++++++++++---------- > arch/aarch64/psci.S | 13 +++++++------ > arch/aarch64/spin.S | 8 ++++---- > 3 files changed, 32 insertions(+), 20 deletions(-) > > diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S > index a9264de..1a5da35 100644 > --- a/arch/aarch64/boot.S > +++ b/arch/aarch64/boot.S > @@ -12,7 +12,7 @@ > .section .init > > .globl _start > - .globl jump_kernel > + .globl jump_kernel > > _start: > cpuid x0, x1 > @@ -22,20 +22,31 @@ _start: > bl setup_stack > > /* > - * EL3 initialisation > + * Boot sequence > + * If CurrentEL == EL3, then goto EL3 initialisation and drop to > + * lower EL before entering the kernel. > + * Else, no initialisation and keep the current EL before > + * entering the kernel. > */ > mrs x0, CurrentEL > cmp x0, #CURRENTEL_EL3 > - b.eq 1f > + beq el3_init As above, I think our failure to initialize anything other than EL3 is a bug, since e.g. we don't know what a number of SCTLR_ELx bits are out-of-reset, including EE. I think we need to rework this into something like: mrs x0, CurrentEL cmp x0, #CURRENTEL_EL3 b.eq init_el3 cmp x0, #CURRENTEL_EL2 b.eq init_el2 cmp x0, #CURRENTEL_EL1 b.eq init_el1 /* this should not happen */ b . > > + /* > + * We stay in the current EL for entering the kernel > + */ > mov w0, #1 > - ldr x1, =flag_no_el3 > + ldr x1, =flag_keep_el > str w0, [x1] Can we get rid of the start_el3/start_no_el3 distinction, and pass the EL in as a parameter to the boot method? Since this it boot-method dependent, I'd like to decide this elsewhere. > > bl setup_stack > - b start_no_el3 > + b start_keep_el > > -1: mov x0, #0x30 // RES1 > + /* > + * EL3 initialisation > + */ > +el3_init: > + mov x0, #0x30 // RES1 > orr x0, x0, #(1 << 0) // Non-secure EL1 > orr x0, x0, #(1 << 8) // HVC enable > > @@ -114,7 +125,7 @@ _start: > > bl gic_secure_init > > - b start_el3 > + b start_el_max > > err_invalid_id: > b . > @@ -141,7 +152,7 @@ jump_kernel: > bl find_logical_id > bl setup_stack // Reset stack pointer > > - ldr w0, flag_no_el3 > + ldr w0, flag_keep_el > cmp w0, #0 // Prepare Z flag > > mov x0, x20 > @@ -150,7 +161,7 @@ jump_kernel: > mov x3, x23 > > b.eq 1f > - br x19 // No EL3 > + br x19 // Keep current EL > > 1: mov x4, #SPSR_KERNEL > > @@ -168,5 +179,5 @@ jump_kernel: > > .data > .align 3 > -flag_no_el3: > +flag_keep_el: > .long 0 > diff --git a/arch/aarch64/psci.S b/arch/aarch64/psci.S > index 01ebe7d..ae02fd6 100644 > --- a/arch/aarch64/psci.S > +++ b/arch/aarch64/psci.S > @@ -45,8 +45,8 @@ vector: > > .text > > - .globl start_no_el3 > - .globl start_el3 > + .globl start_keep_el > + .globl start_el_max > > err_exception: > b err_exception > @@ -101,7 +101,7 @@ smc_exit: > eret > > > -start_el3: > +start_el_max: > ldr x0, =vector > bl setup_vector > > @@ -111,10 +111,11 @@ start_el3: > b psci_first_spin > > /* > - * This PSCI implementation requires EL3. Without EL3 we'll only boot the > - * primary cpu, all others will be trapped in an infinite loop. > + * This PSCI implementation requires the highest EL(EL3 or Armv8-R EL2). > + * Without the highest EL, we'll only boot the primary cpu, all others > + * will be trapped in an infinite loop. > */ > -start_no_el3: > +start_keep_el: > cpuid x0, x1 > bl find_logical_id > cbz x0, psci_first_spin > diff --git a/arch/aarch64/spin.S b/arch/aarch64/spin.S > index 72603cf..533177c 100644 > --- a/arch/aarch64/spin.S > +++ b/arch/aarch64/spin.S > @@ -11,11 +11,11 @@ > > .text > > - .globl start_no_el3 > - .globl start_el3 > + .globl start_keep_el > + .globl start_el_max > > -start_el3: > -start_no_el3: > +start_el_max: > +start_keep_el: > cpuid x0, x1 > bl find_logical_id > > -- > 2.25.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel