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 1DE0BC3DA7E for ; Mon, 29 Jul 2024 16:14:49 +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:In-Reply-To: Content-Transfer-Encoding:Content-Type: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=Sznnm72rJCAM5ymONxt57/g5IRHn/lejME1S0VnYDOc=; b=ZGcyb9NemH0WAhH/2UiZUDbZO7 BNh4l1k9p7O53Gq1yraPX4mAPctZmOUZXKt7fwlZho+unAuSnRbjUJRqV3Q3HEHTPg4fJaQdcYtNh JLJlK387N5M4NZh1Oq99L6oH9BAKHkr0QBxx+4lPeWEXo+KPsnoDWliJEmEu2BoOmfsHqmplo5bsL cauCuyx415Lg2PG6E6vhMvyO4gR/mfPJ2oI96RRUcAhvrDPDF+S3BSORWUNWHQgPBurUXy+pfjenX nzDt4nMfZvRt1J+cV0ypLsvmG7z1VkBteKJ7uGf+ZmUeK++XL0NG7ZyacXH9xvAeEJOUMCledh4up h448pJ/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYT1E-0000000ByCM-1RV5; Mon, 29 Jul 2024 16:14:40 +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 1sYT0n-0000000By9q-2fG1 for linux-arm-kernel@lists.infradead.org; Mon, 29 Jul 2024 16:14:14 +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 5A8E51007; Mon, 29 Jul 2024 09:14:35 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 027BA3F766; Mon, 29 Jul 2024 09:14:08 -0700 (PDT) Date: Mon, 29 Jul 2024 17:14:06 +0100 From: Mark Rutland To: Luca Fancellu Cc: Andre Przywara , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 4/6] aarch64: Introduce EL2 boot code for Armv8-R AArch64 Message-ID: References: <20240716142906.1502802-1-luca.fancellu@arm.com> <20240716142906.1502802-5-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240729_091413_781399_54472BA7 X-CRM114-Status: GOOD ( 34.17 ) 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, Jul 29, 2024 at 04:27:37PM +0100, Luca Fancellu wrote: > Hi Mark, > > >> * - EL2 (Non-secure) > >> - * Entering at EL2 is partially supported. > >> + * Entering at EL2 is partially supported for Armv8-A. > >> + * Entering at EL2 is supported for Armv8-R. > > > > Nit: IIUC ARMv8-R is Secure-only, so this isn't quite right. > > Ok I’ll drop this change > > > > >> * PSCI is not supported when entered in this exception level. > >> */ > >> ASM_FUNC(_start) > >> @@ -76,6 +77,39 @@ reset_at_el2: > >> msr sctlr_el2, x0 > >> isb > >> > >> + /* Detect Armv8-R AArch64 */ > >> + mrs x1, id_aa64mmfr0_el1 > >> + /* > >> + * Check MSA, bits [51:48]: > >> + * 0xf means Armv8-R AArch64. > >> + * If not 0xf, proceed in Armv8-A EL2. > >> + */ > >> + ubfx x0, x1, #48, #4 // MSA > >> + cmp x0, 0xf > >> + bne reset_no_el3 > >> + > >> + /* > >> + * Armv8-R AArch64 is found, check if Linux can be booted. > >> + * Check MSA_frac, bits [55:52]: > >> + * 0x2 means EL1&0 translation regime also supports VMSAv8-64. > >> + */ > >> + ubfx x0, x1, #52, #4 // MSA_frac > >> + cmp x0, 0x2 > >> + /* > >> + * If not 0x2, no VMSA, so cannot boot Linux and dead loop. > >> + * Also, since the architecture guarantees that those CPUID > >> + * fields never lose features when the value in a field > >> + * increases, we use blt to cover it. > >> + */ > >> + blt err_invalid_arch > >> + > >> + /* Start Armv8-R Linux at EL1 */ > >> + mov w0, #SPSR_KERNEL_EL1 > >> + ldr x1, =spsr_to_elx > >> + str w0, [x1] > > > > I'd prefer if we could do this in C code. I'll post a series shortly > > where we'll have consistent cpu_init_arch() hook that we can do this > > under. > > Ok are you suggesting to base this serie on the one you’ll push? Sorry; yes -- I'll send that out shortly, and I'd like to take that as a base. > >> +void cpu_init_armv8r_el2(void) > >> +{ > >> + unsigned long hcr = mrs(hcr_el2); > >> + > >> + msr(vpidr_el2, mrs(midr_el1)); > >> + msr(vmpidr_el2, mrs(mpidr_el1)); > >> + > >> + /* VTCR_MSA: VMSAv8-64 support */ > >> + msr(vtcr_el2, VTCR_EL2_MSA); > > > > I suspect we also need to initialize VSTCR_EL2? > > Ok, I’ve booted Linux and it seems to work fine, is this considered at all when HCR_EL2.VM is off? > Anyway I’ll initialise it, I noticed it’s not done in TF-A. I don't know; the ARMv8-R manual (ARM DDI 0600B.a) says in E1.2.3 DSB: | The ordering requirements of Data Synchronization Barrier instruction is as | follows: | * EL1 and EL0 memory accesses are ordered only with respect to memory accesses | using the same VMID. | * EL2 memory accesses are ordered only with respect to other EL2 memory | accesses. ... which seems to apply regardless of HCR_EL2.VM? It's probably worth clarifying with the relevant architects. > > ... and don't we also need to initialize VSCTLR_EL2 to give all CPUs the > > same VMID? Otherwise barriers won't work at EL1 and below... > > I can see TF-A is initialising it so I’ll do the same Great; thanks! > > > > >> + > >> + /* > >> + * HCR_EL2.ENSCXT is written unconditionally even if in some cases it's > >> + * RES0 (when FEAT_CSV2_2 or FEAT_CSV2_1p2 are not implemented) in order > >> + * to simplify the code, but it's safe in this case as the write would be > >> + * ignored when not implemented and would remove the trap otherwise. > >> + */ > >> + hcr |= HCR_EL2_ENSCXT_NOTRAP; > > > > I'd prefer if we can do the necessary checks. IIUC we can do this with a > > helper, e.g. > > > > static bool cpu_has_scxt(void) > > { > > unsigned long csv2 = mrs_field(ID_AA64PFR0_EL1, CSV2); > > if (csv2 >= 2) > > return true; > > if (csv2 < 1) > > return false; > > return mrs_field(ID_AA64PFR1_EL1, CSV2_frac) >= 2; > > } > > > > ... then here we can have: > > > > if (cpu_has_scxt()) > > hcr |= HCR_EL2_ENSCXT_NOTRAP; > > Ok I’ll do > > > > >> + > >> + if (mrs_field(ID_AA64PFR0_EL1, RAS) >= 2) > >> + hcr |= HCR_EL2_FIEN_NOTRAP; > >> + > >> + if (cpu_has_pauth()) > >> + hcr |= HCR_EL2_APK_NOTRAP | HCR_EL2_API_NOTRAP; > >> + > >> + msr(hcr_el2, hcr); > >> + isb(); > >> + msr(CNTFRQ_EL0, COUNTER_FREQ); > >> +} > > > > I believe we also need to initialize: > > > > * CNTVOFF_EL2 (for timers to work correctly) > > * CNTHCTL_EL2 (for timers to not trap) > > * CPTR_EL2 (for FP to not trap) > > * MDCR_EL2 (for PMU & debug to not trap) > > Sure, I’ll reset them like in TF-A. Perfect! Mark.