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=-12.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 580D2C4708F for ; Fri, 4 Jun 2021 13:50:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B89A613FF for ; Fri, 4 Jun 2021 13:50:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230351AbhFDNw2 (ORCPT ); Fri, 4 Jun 2021 09:52:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:33790 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230124AbhFDNw0 (ORCPT ); Fri, 4 Jun 2021 09:52:26 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 32DF9613C9; Fri, 4 Jun 2021 13:50:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622814640; bh=K/GY5g+siZhU8v4b9BjhoSm+Dq5y6/LVafctSr5ng7M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tuGi9PZakCL+fNw4WVIFTAUpGmeNIybdPOKJFFJC5ku5rdXeW5h+ZX58GLu00B9OY i2NrTyCO0YUn2C6PUJ+Td35BwvFrRUm9PjzSK48kXJ29qsVs4fp1JDGeF5r6D1c4WI cbwEWgvAFyHboCzZIyKX08XxYOWRNy6PQN/ZGWVFcSe77GLdBQ5LW29xFevZodXr6L LHsaZ5JJXGqq/n7ygGIRolH2hOF4JjgRd+Vww5zMG0rAM1kngHUZI3RT2RpNpQX3kR T46/bL7CIVZDfkVWxXa3KObEC5CIEaX/6nY+7+VJttaovuoSFQuthSUupnhdppyly6 NrIFRbX8xMM8A== Date: Fri, 4 Jun 2021 14:50:33 +0100 From: Will Deacon To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , Dietmar Eggemann , Daniel Bristot de Oliveira , Valentin Schneider , kernel-team@android.com Subject: Re: [PATCH v8 02/19] arm64: Allow mismatched 32-bit EL0 support Message-ID: <20210604135033.GB2793@willie-the-truck> References: <20210602164719.31777-1-will@kernel.org> <20210602164719.31777-3-will@kernel.org> <20210603123715.GA48596@C02TD0UTHF1T.local> <20210603174413.GC1170@willie-the-truck> <20210604093808.GA64162@C02TD0UTHF1T.local> <20210604110526.GF2318@willie-the-truck> <20210604120352.GA67240@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210604120352.GA67240@C02TD0UTHF1T.local> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 04, 2021 at 01:04:27PM +0100, Mark Rutland wrote: > On Fri, Jun 04, 2021 at 12:05:27PM +0100, Will Deacon wrote: > > On Fri, Jun 04, 2021 at 10:38:08AM +0100, Mark Rutland wrote: > > > On Thu, Jun 03, 2021 at 06:44:14PM +0100, Will Deacon wrote: > > > > On Thu, Jun 03, 2021 at 01:37:15PM +0100, Mark Rutland wrote: > > > > > On Wed, Jun 02, 2021 at 05:47:02PM +0100, Will Deacon wrote: > > > > > > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > > > > > > That said. I reckon this could be much cleaner if we maintained separate > > > > > caps: > > > > > > > > > > ARM64_ALL_CPUS_HAVE_32BIT_EL0 > > > > > ARM64_SOME_CPUS_HAVE_32BIT_EL0 > > > > > > > > > > ... and allow arm64_mismatched_32bit_el0 to be set dependent on > > > > > ARM64_SOME_CPUS_HAVE_32BIT_EL0. With that, this can be simplified to: > > > > > > > > > > static inline bool system_supports_32bit_el0(void) > > > > > { > > > > > return (cpus_have_const_cap(ARM64_ALL_CPUS_HAVE_32BIT_EL0)) || > > > > > static_branch_unlikely(&arm64_mismatched_32bit_el0)) > > > > > > > > Something similar was discussed in November last year but this falls > > > > apart with late onlining because its not generally possible to tell whether > > > > you've seen all the CPUs or not. > > > > > > Ah; is that for when your boot CPU set is all AArch32-capable, but a > > > late-onlined CPU is not? > > > > > > I assume that we require at least one of the set of boot CPUs to be > > > AArch32 cpable, and don't settle the compat hwcaps after userspace has > > > started. > > > > Heh, you assume wrong :) > > > > When we allow the mismatch, then we do actually defer initialisation of > > the compat hwcaps until we see a 32-bit CPU. That's fine, as they won't > > be visible to userspace until then anyway (PER_LINUX32 is unavailable). > > That sounds quite scary, to me, though I don't have a concrete problem > to hand. :/ > > Do we really need to support initializing that so late? For all other > caps we've settled things when the boot CPUs come up, and it's > unfortunate to have to treat this differently. I think it's the nature of the beast, unfortunately. Since we're talking about multiple generations of SoCs rather than just one oddball design, then placing artificial restrictions on the boot CPUs doesn't feel like it will last very long. > I'll go see if there's anything that's liable to break today. Please let me know if you find anything. Will