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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 EB0BFC388F7 for ; Fri, 13 Nov 2020 09:37:04 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 747BA2145D for ; Fri, 13 Nov 2020 09:37:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AKwW8ct8"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="zQWpJ/KP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 747BA2145D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=mgdZ1xLl57vXEwzZ9NQXTrCkyxiN08HUB06gLWiZyqU=; b=AKwW8ct8+WLhjYKnlwAdtvZ/V bzmjPhZPqtP9nyT9oquvYF6WYI/ekSIuZfQM4Ism/jHnBk+2iZXG2viSnc7Z2SNjtey85DFFVZ+4z NKkuByUdYWQIWLGeQ8uV8ub1JVDhLJg6k3KkubOrKKInIq63O1fYfiliQBxYDCohpXqv/BWn+vqfD rwPWFnakb1mJqaLojan9qPnEWKwUs10q/2N4tTaTWL+AX57qe8wVwlTHUFhjdgsycpN40fKXJapaz SMRa1ev7qfZajxLyhx8NfTieD6VOBozHLe2h4iLNFQQLpQN+MbFTLrOPICtFxa5+lUmIlxzFkXgJi UUQ3N+fBg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVVZ-00021B-Ds; Fri, 13 Nov 2020 09:36:41 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVVV-0001zf-UQ for linux-arm-kernel@lists.infradead.org; Fri, 13 Nov 2020 09:36:38 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 63EE222240; Fri, 13 Nov 2020 09:36:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605260196; bh=Awbze+yn+sds2zWgzVstLWw9uJr4cE6in8SvDz0W3C4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zQWpJ/KPcFLuU9qRwqAVsOjXoZWMHlyxIG0jZaGNU0Kzkml7x7qqhmuCj1Ut2G2s6 8LYuupsLS6ia26YI2GYqDrcAbQlziwz0ucqBbQxmltYbtZXBWrlUYXGBDbtsabuD2R q+0rkeYJlXuPW54IH7qyJN6ryDoVZKQMfcqk1+/0= Date: Fri, 13 Nov 2020 09:36:30 +0000 From: Will Deacon To: Catalin Marinas Subject: Re: [PATCH v2 2/6] arm64: Allow mismatched 32-bit EL0 support Message-ID: <20201113093630.GA21075@willie-the-truck> References: <20201109213023.15092-1-will@kernel.org> <20201109213023.15092-3-will@kernel.org> <20201111191043.GA5125@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201111191043.GA5125@gaia> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201113_043638_070617_E5DD5B6C X-CRM114-Status: GOOD ( 20.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, kernel-team@android.com, Quentin Perret , Peter Zijlstra , Marc Zyngier , Qais Yousef , Greg Kroah-Hartman , Suren Baghdasaryan , Morten Rasmussen , linux-arm-kernel@lists.infradead.org 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 Wed, Nov 11, 2020 at 07:10:44PM +0000, Catalin Marinas wrote: > On Mon, Nov 09, 2020 at 09:30:18PM +0000, Will Deacon wrote: > > +static bool has_32bit_el0(const struct arm64_cpu_capabilities *entry, int scope) > > +{ > > + if (!has_cpuid_feature(entry, scope)) > > + return allow_mismatched_32bit_el0; > > I still don't like overriding the cpufeature mechanism in this way. What about > something like below? It still doesn't fit perfectly but at least the > capability represents what was detected in the system. We then decide in > system_supports_32bit_el0() whether to allow asymmetry. There is an > extra trick to park a non-AArch32 capable CPU in has_32bit_el0() if it > comes up late and the feature has already been advertised with > !allow_mismatched_32bit_el0. I deliberately allow late onlining of 64-bit-only cores and I don't think this is something we should forbid (although it's not clear from your patch when allow_mismatched_32bit_el0 gets set). Furthermore, killing CPUs from the matches callback feels _very_ dodgy to me, as it's invoked indirectly by things such as this_cpu_has_cap(). > I find it clearer, though I probably stared at it more than at your > patch ;). Yeah, swings and roundabouts... I think we're quibbling on implementation details a bit here whereas we should probably be focussing on what to do about execve() and CPU hotplug. Your patch doesn't apply on top of my series or replace this one, so there's not an awful lot I can do with it. I'm about to post a v3 with a tentative solution for execve(), so please could you demonstrate your idea on top of that so I can see how it fits together? I'd like to move on from the "I don't like this" (none of us do) discussion and figure out the functional aspects, if possible. We can always paint it a different colour later on, but we don't even have a full solution yet. Thanks, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel