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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 7502CC4708F for ; Fri, 4 Jun 2021 12:04:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 58D856140C for ; Fri, 4 Jun 2021 12:04:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230264AbhFDMG1 (ORCPT ); Fri, 4 Jun 2021 08:06:27 -0400 Received: from foss.arm.com ([217.140.110.172]:37578 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229740AbhFDMG0 (ORCPT ); Fri, 4 Jun 2021 08:06:26 -0400 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 2ADBF2B; Fri, 4 Jun 2021 05:04:40 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.6.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 51AD43F73D; Fri, 4 Jun 2021 05:04:35 -0700 (PDT) Date: Fri, 4 Jun 2021 13:04:27 +0100 From: Mark Rutland To: Will Deacon 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: <20210604120352.GA67240@C02TD0UTHF1T.local> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210604110526.GF2318@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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'll go see if there's anything that's liable to break today. Thanks, Mark 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=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5CD46C47083 for ; Fri, 4 Jun 2021 12:06:17 +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 2A74B6140C for ; Fri, 4 Jun 2021 12:06:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A74B6140C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@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=OU+OIPFDikdZOu8APuWAOfnk5dgmmJ8Hj6zylhKYDXg=; b=P0VzJUCyq/CA9f fXYjOHT1vBpWa36cBqlIdwDp4wA+SUVksdGCLrE4yyYzptAAW9r/gkWzfINGUP/b4QXmg6xo45h8B EMOjYJLvcs8z3od54j9WYBjTU2fegBolVHIKWtWF4gZFh3csQ3t08ckUdl2QJ0z4M8N3/arYTouH0 EFu+Ol5CUbcIEZQMjD5RX7eQW6GEtcg2uRpLtMaOeV93LcB8L05ufq0LIE+YLr2cTu02XTtOKqp4T nRx90c5bokC+4ntP7QZGs4BLNEHdDxDvU6vjJkRKu/ZBL7XIOFYIafPqHAKoKgVSsCqGCKhuTCnla hZcCyRJsmjW7pflbu1ZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lp8ZG-00DSSF-Se; Fri, 04 Jun 2021 12:04:51 +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 1lp8Z8-00DSPm-KO for linux-arm-kernel@lists.infradead.org; Fri, 04 Jun 2021 12:04:47 +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 2ADBF2B; Fri, 4 Jun 2021 05:04:40 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.6.137]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 51AD43F73D; Fri, 4 Jun 2021 05:04:35 -0700 (PDT) Date: Fri, 4 Jun 2021 13:04:27 +0100 From: Mark Rutland To: Will Deacon 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: <20210604120352.GA67240@C02TD0UTHF1T.local> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210604110526.GF2318@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210604_050442_757596_039C5ED5 X-CRM114-Status: GOOD ( 23.76 ) 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 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'll go see if there's anything that's liable to break today. Thanks, Mark _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel