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 E1FD3C43334 for ; Tue, 14 Jun 2022 08:27:06 +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:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=em98KJFosuvKCsKf6MvVMUQJ4menn0qTx2YdxVEOekY=; b=Hu05DfiAVso5RB dGVqjq6tUPlpqC77Z0SNIs6T9zUr12i3fbrDWKS+9SyL+nQcL+fngOHIRvGPonakhUDFcIZQ5XAPL WJEz7xPw6PFy3W4QFbCT0/264+4fIvdmNTqoVjmWGaUsl4kQb/iUv3qdsquYtcgSR7fkkK71YFt0j 5KfbBfGaabLP0rh8xefeOP/N6Xd3aA/VCrOpei1Tg/7oEwqMZEE+5DPoL86Rql25dNjQGWzcYqX9l d64QF0ex9wyLYG5D5MgslqSMBmXCqIG6p7XHXU8gPSTHKdrfcP/jNyEnt7JAMEeu3sHebXbnmtkTM pjePrBQJz0smMIfYLtKQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o11sC-008Eog-08; Tue, 14 Jun 2022 08:26:04 +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 1o11s1-008ElH-9C for linux-arm-kernel@lists.infradead.org; Tue, 14 Jun 2022 08:25: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 3C2F723A; Tue, 14 Jun 2022 01:25:47 -0700 (PDT) Received: from [10.162.40.17] (unknown [10.162.40.17]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 286513F66F; Tue, 14 Jun 2022 01:25:43 -0700 (PDT) Message-ID: Date: Tue, 14 Jun 2022 13:55:41 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4 02/26] arm64: mm: make vabits_actual a build time constant if possible Content-Language: en-US To: Ard Biesheuvel , linux-arm-kernel@lists.infradead.org Cc: linux-hardening@vger.kernel.org, Marc Zyngier , Will Deacon , Mark Rutland , Kees Cook , Catalin Marinas , Mark Brown References: <20220613144550.3760857-1-ardb@kernel.org> <20220613144550.3760857-3-ardb@kernel.org> From: Anshuman Khandual In-Reply-To: <20220613144550.3760857-3-ardb@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220614_012553_484110_091BAAC1 X-CRM114-Status: GOOD ( 24.57 ) 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 6/13/22 20:15, Ard Biesheuvel wrote: > Currently, we only support 52-bit virtual addressing on 64k pages But going forward, will support on 4K/16K pages as well via FEAT_LPA2. > configurations, and in all other cases, vabits_actual is guaranteed to > equal VA_BITS (== VA_BITS_MIN). So get rid of the variable entirely in > that case. The change here does not really get rid of vabit_actual in those cases either, it just makes it a build time constant AFAICS. --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -174,7 +174,11 @@ #include #include +#if VA_BITS > 48 extern u64 vabits_actual; +#else +#define vabits_actual ((u64)VA_BITS) +#endif > > While at it, move the assignment out of the asm entry code - it has no > need to be there. This also changes when vabits_actual gets evaluated ? Then how would it know, that CPU needs to be stuck in kernel (CPU_STUCK_REASON_52_BIT_VA) in case all secondary CPUs do not support large VA feature ? Looking at the sequence... secondary_entry OR secondary_holding_pen secondary_startup __cpu_secondary_check52bitva primary_entry __create_page_tables <--- original position __primary_switch start_kernel setup_arch paging_init <--- new position It might still be possible for the secondary cpu start up sequence to validate LVA support across the platform, but still why even send vabits_actual evaluation down the line until paging_init(). Ideally should not it be evaluated as early as possible during boot. Hence, wondering - what is the real benefit here ? > > Signed-off-by: Ard Biesheuvel > --- > arch/arm64/include/asm/memory.h | 4 ++++ > arch/arm64/kernel/head.S | 15 +-------------- > arch/arm64/mm/mmu.c | 15 ++++++++++++++- > 3 files changed, 19 insertions(+), 15 deletions(-) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 0af70d9abede..c751cd9b94f8 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -174,7 +174,11 @@ > #include > #include > > +#if VA_BITS > 48 > extern u64 vabits_actual; > +#else > +#define vabits_actual ((u64)VA_BITS) > +#endif > > extern s64 memstart_addr; > /* PHYS_OFFSET - the physical address of the start of memory. */ > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index 1cdecce552bb..dc07858eb673 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -293,19 +293,6 @@ SYM_FUNC_START_LOCAL(__create_page_tables) > adrp x0, idmap_pg_dir > adrp x3, __idmap_text_start // __pa(__idmap_text_start) > > -#ifdef CONFIG_ARM64_VA_BITS_52 > - mrs_s x6, SYS_ID_AA64MMFR2_EL1 > - and x6, x6, #(0xf << ID_AA64MMFR2_LVA_SHIFT) > - mov x5, #52 > - cbnz x6, 1f > -#endif > - mov x5, #VA_BITS_MIN > -1: > - adr_l x6, vabits_actual > - str x5, [x6] > - dmb sy > - dc ivac, x6 // Invalidate potentially stale cache line > - > /* > * VA_BITS may be too small to allow for an ID mapping to be created > * that covers system RAM if that is located sufficiently high in the > @@ -713,7 +700,7 @@ SYM_FUNC_START(__enable_mmu) > SYM_FUNC_END(__enable_mmu) > > SYM_FUNC_START(__cpu_secondary_check52bitva) > -#ifdef CONFIG_ARM64_VA_BITS_52 > +#if VA_BITS > 48 Just curious - why this is any better ? Although both (VA_BITS > 48) and CONFIG_ARM64_VA_BITS_52 are build time constants. > ldr_l x0, vabits_actual > cmp x0, #52 > b.ne 2f > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index 7148928e3932..17b339c1a326 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -46,8 +46,10 @@ > u64 idmap_t0sz = TCR_T0SZ(VA_BITS_MIN); > u64 idmap_ptrs_per_pgd = PTRS_PER_PGD; > > -u64 __section(".mmuoff.data.write") vabits_actual; > +#if VA_BITS > 48 > +u64 vabits_actual __ro_after_init = VA_BITS_MIN; > EXPORT_SYMBOL(vabits_actual); > +#endif > > u64 kimage_vaddr __ro_after_init = (u64)&_text; > EXPORT_SYMBOL(kimage_vaddr); > @@ -772,6 +774,17 @@ void __init paging_init(void) > { > pgd_t *pgdp = pgd_set_fixmap(__pa_symbol(swapper_pg_dir)); > > +#if VA_BITS > 48 > + if (cpuid_feature_extract_unsigned_field( > + read_sysreg_s(SYS_ID_AA64MMFR2_EL1), > + ID_AA64MMFR2_LVA_SHIFT)) > + vabits_actual = VA_BITS; > + > + /* make the variable visible to secondaries with the MMU off */ > + dcache_clean_inval_poc((u64)&vabits_actual, > + (u64)&vabits_actual + sizeof(vabits_actual)); > +#endif > + > map_kernel(pgdp); > map_mem(pgdp); > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel