From patchwork Thu Oct 10 17:15:14 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suzuki K Poulose X-Patchwork-Id: 175790 Delivered-To: patch@linaro.org Received: by 2002:ac9:3c86:0:0:0:0:0 with SMTP id w6csp2583103ocf; Thu, 10 Oct 2019 10:15:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqzYfECl6iUsNnNTU7bWfIZEHGlzowr8g+l/gxgDhczksDORwsJJ84Sj6Hl2hqkLGT+YWyw0 X-Received: by 2002:aa7:d842:: with SMTP id f2mr9307590eds.27.1570727736115; Thu, 10 Oct 2019 10:15:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570727736; cv=none; d=google.com; s=arc-20160816; b=KX1u5Y8lJu19BZ5zFH09COi8Jtmrrndjf8IGLubpBPgO9zyvzJAt/egrTWpyYhnRqJ umaVzZp+OsoT3/u4+tdrwUB3jkZVYi7wq5gBYoq9gdn2O9g16TJa31YPi8F9LIIncv/s In/ISEa2aXDIhHTYJGalD8m4GcBAPSms63cG0ZpK5PulEW+rqdqp0tgCDgUKoInmcpi+ s0cmi5YiABW7ygtZL5qGJ/YRIGjw5I/Pz851RWARum5b2DhcdBsSKvaZiX+OtOlJndXO 4Pyi8flxZAdKcY6CGLQoo08vyB2bFG6KT0MofK4grefUhhDEh0Bd9bA4HBS6xKmUeiuI s9oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=RO7vogiVqxGorKJqyXb9wP+bNRZrG0D8bG64JW/cE4Q=; b=fdl6eNQC6rmsrNWTmsNO585gLu+deiFmjtYnNUezo2pegIt9Hoiu5bhFQzpOVAtfrx gYEVUtMhXlM9ZuAMv9OUhi6xGLY0iaojincScPicQO+gJbBHfjxkOAwqI0D9tr9AHYC9 GaXY3zWu8vsO1faGTggSwoLI907lovTjaVTkb73wWSbqSN9THE9Gi0omSZfUGCknMnGj ae80iGkIMpCQ/9yQHDfa8GaOV3SfsTPfOItjuidepYELj/Z0Ai54uwORaPj46S2C1r7V 0w8OUOqpFzjjauyOqSWRBXSuFGHelJq4qxMz74eNxbc2VVSaWALsPy922AuDkLsOfMBA 50gQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l20si3417247ejb.111.2019.10.10.10.15.35; Thu, 10 Oct 2019 10:15:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726767AbfJJRPf (ORCPT + 21 others); Thu, 10 Oct 2019 13:15:35 -0400 Received: from foss.arm.com ([217.140.110.172]:36338 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbfJJRPe (ORCPT ); Thu, 10 Oct 2019 13:15:34 -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 4252928; Thu, 10 Oct 2019 10:15:34 -0700 (PDT) Received: from dawn-kernel.cambridge.arm.com (unknown [10.1.197.116]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 3EA723F71A; Thu, 10 Oct 2019 10:15:33 -0700 (PDT) From: Suzuki K Poulose To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, will@kernel.org, mark.rutland@arm.com, catalin.marinas@arm.com, dave.martin@arm.com, Suzuki K Poulose Subject: [PATCH 0/3] arm64: Fix support for systems without FP/SIMD Date: Thu, 10 Oct 2019 18:15:14 +0100 Message-Id: <20191010171517.28782-1-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series fixes the original support for systems without FP/SIMD. We have three set of issues with the current code : 1) We detect the absence of FP/SIMD after the SMP cpus are brought online (i.e, SYSTEM scope). This means, some of the early kernel threads could run with their TIF_FOREIGN_FPSTATE flag set which might be inherited by applications forked by them (e.g, modprobe from initramfs). Also we allow a hotplugged CPU to boot successfully even if it doesn't have the FP/SIMD when we have decided otherwise at boot and have now advertised the ELF HWCAP for the userspace. Fix this by turning this to a BOOT_RESTRICTED_CPU_LOCAL feature to allow the detection of the feature the very moment a CPU turns up without FP/SIMD and also prevent a conflict after SMP boot. 2) As mentioned above, some tasks could have the TIF flag set, which will never be cleared after we detect the capability. Thus they could get stuck indefinitely in do_notfiy_resume(). Fix this by clearing the TIF flag for such tasks but continuing to avoid the save/restore of the FP state. 3) The compat ELF_HWCAP bits are statically initialised to indicate that the FP/SIMD support is available. This must be updated dynamically to provide the correct flags to the userspace. Tested with a 32bit Debian Jessie fs on Fast model (with and without FP support). Suzuki K Poulose (3): arm64: cpufeature: Fix the type of no FP/SIMD capability arm64: nofpsmid: Clear TIF_FOREIGN_FPSTATE flag for early tasks arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly arch/arm64/kernel/cpufeature.c | 39 ++++++++++++++++++++++++++++++---- arch/arm64/kernel/fpsimd.c | 26 ++++++++++++++--------- 2 files changed, 51 insertions(+), 14 deletions(-) -- 2.21.0