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.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 F2446ECE58C for ; Fri, 11 Oct 2019 14:21:51 +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 C224F206A1 for ; Fri, 11 Oct 2019 14:21:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lT05Y/Ra" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C224F206A1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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.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=CT3M3+Ca+nj2BuTrXBQf7e9nDifMWHISoCsL63X5gdM=; b=lT05Y/RaYBfElU vb7U1tasyJZI6qY1NTVFGjO3Qar4u9yUObDk5poX4bBXHinLVGrsAgyetTj0QgdlCeyKEY5e/c8Mw GPW8RBeBY2m03eC6BhzDgFG6BurSXcOVJzdRWs1YjbNW49Df11t1RnTSuLHA67bvGHsxaT5P0yi/U sAye0hvOJa4FldqG9uKV/+80kqoukoj8+e3l9i743KhHq2Ctw6syuLgjqAy7tQ1lRxTx1tMv+IRBx g88oCABvlVgM1uhmrYZEbFA9Hj9DwOTqwJnA7S0wrHHuTVQjvySsBnE9jcwNx8T+jYlLsKJXQ5za4 T18Yie/PFvmXTqyRd3Vw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIvnc-0004pU-Jw; Fri, 11 Oct 2019 14:21:44 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iIvnZ-0004p8-Pw for linux-arm-kernel@lists.infradead.org; Fri, 11 Oct 2019 14:21:43 +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 2AA3E142F; Fri, 11 Oct 2019 07:21:41 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 43A133F68E; Fri, 11 Oct 2019 07:21:40 -0700 (PDT) Date: Fri, 11 Oct 2019 15:21:38 +0100 From: Dave Martin To: Suzuki K Poulose Subject: Re: [PATCH 1/3] arm64: cpufeature: Fix the type of no FP/SIMD capability Message-ID: <20191011142137.GH27757@arm.com> References: <20191010171517.28782-1-suzuki.poulose@arm.com> <20191010171517.28782-2-suzuki.poulose@arm.com> <20191011113620.GG27757@arm.com> <4ba5c423-4e2a-d810-cd36-32a16ad42c91@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4ba5c423-4e2a-d810-cd36-32a16ad42c91@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191011_072141_930751_C5A95460 X-CRM114-Status: GOOD ( 24.85 ) 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: mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-kernel@vger.kernel.org, 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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 11, 2019 at 01:13:18PM +0100, Suzuki K Poulose wrote: > Hi Dave > > On 11/10/2019 12:36, Dave Martin wrote: > >On Thu, Oct 10, 2019 at 06:15:15PM +0100, Suzuki K Poulose wrote: > >>The NO_FPSIMD capability is defined with scope SYSTEM, which implies > >>that the "absence" of FP/SIMD on at least one CPU is detected only > >>after all the SMP CPUs are brought up. However, we use the status > >>of this capability for every context switch. So, let us change > >>the scop to LOCAL_CPU to allow the detection of this capability > >>as and when the first CPU without FP is brought up. > >> > >>Also, the current type allows hotplugged CPU to be brought up without > >>FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace > >>up. Fix both of these issues by changing the capability to > >>BOOT_RESTRICTED_LOCAL_CPU_FEATURE. > >> > >>Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD") > >>Cc: Will Deacon > >>Cc: Mark Rutland > >>Cc: Catalin Marinas > >>Signed-off-by: Suzuki K Poulose > >>--- > >> arch/arm64/kernel/cpufeature.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > >>index 9323bcc40a58..0f9eace6c64b 100644 > >>--- a/arch/arm64/kernel/cpufeature.c > >>+++ b/arch/arm64/kernel/cpufeature.c > >>@@ -1361,7 +1361,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > >> { > >> /* FP/SIMD is not implemented */ > >> .capability = ARM64_HAS_NO_FPSIMD, > >>- .type = ARM64_CPUCAP_SYSTEM_FEATURE, > >>+ .type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE, > > > >ARM64_HAS_NO_FPSIMD is really a disability, not a capability. > > > >Although we have other things that smell like this (CPU errata for > >example), I wonder whether inverting the meaning in the case would > >make the situation easier to understand. > > Yes, it is indeed a disability, more on that below. > > > > >So, we'd have ARM64_HAS_FPSIMD, with a minimum (signed) feature field > >value of 0. Then this just looks like an ARM64_CPUCAP_SYSTEM_FEATURE > >IIUC. We'd just need to invert the sense of the check in > >system_supports_fpsimd(). > > This is particularly something we want to avoid with this patch. We want > to make sure that we have the up-to-date status of the disability right > when it happens. i.e, a CPU without FP/SIMD is brought up. With SYSTEM_FEATURE > you have to wait until we bring all the CPUs up. Also, for HAS_FPSIMD, > you must wait until all the CPUs are up, unlike the negated capability. I don't see why waiting for the random defective early CPU to come up is better than waiting for all the early CPUs to come up and then deciding. Kernel-mode NEON aside, the status of this cap should not matter until we enter userspace for the first time. The only issue is if e.g., crypto drivers that can use kernel-mode NEON probe for it before all early CPUs are up, and so cache the wrong decision. The current approach doesn't cope with that anyway AFAICT. > >> .min_field_value = 0, > > > >(Does .min_field_value == 0 make sense, or is it even used? I thought > >only the default has_cpuid_feature() match logic uses that.) > > True, it is not used for this particular case. Ok, just wondering. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel