Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4534405ybl; Mon, 13 Jan 2020 15:38:23 -0800 (PST) X-Google-Smtp-Source: APXvYqxe3C9jNZrdCmH0WhMCz0fhqG+Nrv+EgNQGRveSCb+5KxulL9lyuohWLLO20UQVvIhGVtN3 X-Received: by 2002:aca:e106:: with SMTP id y6mr15059068oig.131.1578958703666; Mon, 13 Jan 2020 15:38:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578958703; cv=none; d=google.com; s=arc-20160816; b=L04GmP9ApORJTKSJ71bNkp9D1/31Z9JKqZ0Tye5rAbEK87XQB5WoiJJO+EhXxywAEB 3klOplwkuctI31SjWfrcQCG8j/0ltmYSmu3rxIWUUol5coIqSy4EyA7Wp97d2rOoKjUc KmqjuXyoJ7GwwiZInAPW63X/4BRgWcnbSD1JWfpGOk/HoKrL3Rwx35yxnQBoVItDi+s1 qv1wmpa6snbDgpbSvxO49T/kcKVjQp0e04/COt3LisdwsO2FLTxG5xWwh/kc8QYoKIYL +1olNTcP6SvyR2Zxjs2sJrodB8VgKQD1U9eXexZMGsluCnpEHF7y/qrXGU/Ks3mTIyx6 SjYw== 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=MbCI/cfhOeFtAIehXV3K77D9zZ0Cpjuzs7Y51igdKsE=; b=ulIo5ZDOkq2txg38aQI3fGiQqWMJLHhDaxK03q+S37pW8egHBK0XVyxYYhzEjNL4DJ YHwqj8mnPC1GFxX9BPrfBDK1ATMRVA5bsb3x8k73IAUC8IN+YU2T2TYhYGnxjRH/JQep 4vGWQKspdTujz1gDhSOZX9o7PMvLUyH1D/1Tf3DQxXxcffPKwdnI88T34aqx7w+qTTiI DFUZe6e1EC5Hpz+tKB++EqcPHeSBhT7XTSQoHtt+fAkt6rdqq3Hpdt0MCHhORZ4Ms02u a2P/sAotviScJownDVWrbbZcC519eY3tlV3i1nuTa7MjCH71ixKZoHvCyUDvSH322ZNR JXxw== 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 14si6431385oij.200.2020.01.13.15.38.10; Mon, 13 Jan 2020 15:38:23 -0800 (PST) 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 S1729318AbgAMXau (ORCPT + 99 others); Mon, 13 Jan 2020 18:30:50 -0500 Received: from foss.arm.com ([217.140.110.172]:45614 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727282AbgAMXat (ORCPT ); Mon, 13 Jan 2020 18:30:49 -0500 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 D562711B3; Mon, 13 Jan 2020 15:30:48 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id BA11C3F68E; Mon, 13 Jan 2020 15:30:47 -0800 (PST) From: Suzuki K Poulose To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, will@kernel.org, maz@kernel.org, catalin.marinas@arm.com, ard.biesheuvel@linaro.org, mark.rutland@arm.com, Suzuki K Poulose Subject: [PATCH v3 0/7] arm64: Fix support for no FP/SIMD Date: Mon, 13 Jan 2020 23:30:16 +0000 Message-Id: <20200113233023.928028-1-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series fixes the support for systems without FP/SIMD unit. We detect the absence of FP/SIMD after the SMP cpus are brought online (i.e, SYSTEM scope). This means, 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. The COMPAT ELF_HWCAPs were statically set to indicate the availability of VFP. Make it dynamic to set the appropriate bits. Also, some of the early kernel threads (including init) could run with their TIF_FOREIGN_FPSTATE flag set which might be inherited by applications forked by them (e.g, modprobe from initramfs). Now, if we detect the absence of FP/SIMD we stop clearing the TIF flag in fpsimd_restore_current_state(). This could cause the applications stuck in do_notify_resume() looping forever to clear the flag. Fix this by clearing the TIF flag in fpsimd_restore_current_state() for the tasks that may have it set. This series also categorises the functions dealing with fpsimd into two : - Call permitted with missing FP/SIMD support. But we bail out early in the function. This is for functions exposed to the generic kernel code. - Calls not permitted with missing FP/SIMD support. These are functions which deal with the CPU/Task FP/SIMD registers and/or meta-data. The callers must check for the support before invoking them. See the last patch in the series for details. Also make sure that the SVE is initialised where supported, before the FP/SIMD is used by the kernel. Tested with debian armel initramfs and rootfs. The arm64 doesn't have a soft-float ABI, thus haven't tested it with 64bit userspace. Applies on linux-aarch64 for-next/core Changes since v2: - Rebase on to for-next/core, resolved conflict with the E0PD handling changes - Address comments from Catalin - Remove warnings from static functions - Add WARN_ON in may_use_simd() if called before initializing capabilities. - Add "active" hook for FP regset - Remove dangerous WARN_ON from KVM, replaced with an additional check to make sure that the FP/SIMD is always trapped. - Added tags from Catalin, Marc Suzuki K Poulose (7): arm64: Introduce system_capabilities_finalized() marker arm64: fpsimd: Make sure SVE setup is complete before SIMD is used arm64: cpufeature: Fix the type of no FP/SIMD capability arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations arm64: signal: nofpsimd: Handle fp/simd context for signal frames arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly arch/arm64/include/asm/cpufeature.h | 5 +++ arch/arm64/include/asm/kvm_host.h | 2 +- arch/arm64/include/asm/simd.h | 8 +++- arch/arm64/kernel/cpufeature.c | 67 +++++++++++++++++++---------- arch/arm64/kernel/fpsimd.c | 30 +++++++++++-- arch/arm64/kernel/process.c | 2 +- arch/arm64/kernel/ptrace.c | 21 +++++++++ arch/arm64/kernel/signal.c | 6 ++- arch/arm64/kernel/signal32.c | 4 +- arch/arm64/kvm/hyp/switch.c | 10 ++++- 10 files changed, 121 insertions(+), 34 deletions(-) -- 2.24.1