From: Suzuki K Poulose <suzuki.poulose@arm.com> To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, will@kernel.org, maz@kernel.org, mark.rutland@arm.com, dave.martin@arm.com, catalin.marinas@arm.com, ard.biesheuvel@linaro.org, christoffer.dall@arm.com, Suzuki K Poulose <suzuki.poulose@arm.com> Subject: [PATCH v2 0/7] arm64: Fix support for no FP/SIMD Date: Tue, 17 Dec 2019 18:33:55 +0000 [thread overview] Message-ID: <20191217183402.2259904-1-suzuki.poulose@arm.com> (raw) 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 v5.5-rc2. 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/mmu.h | 2 +- arch/arm64/include/asm/simd.h | 8 +++- arch/arm64/kernel/cpufeature.c | 65 +++++++++++++++++++---------- arch/arm64/kernel/fpsimd.c | 32 ++++++++++++-- arch/arm64/kernel/process.c | 2 +- arch/arm64/kernel/ptrace.c | 12 ++++++ arch/arm64/kernel/signal.c | 17 +++++++- arch/arm64/kernel/signal32.c | 12 +++++- arch/arm64/kvm/hyp/switch.c | 9 ++++ 11 files changed, 132 insertions(+), 34 deletions(-) -- 2.23.0
WARNING: multiple messages have this Message-ID (diff)
From: Suzuki K Poulose <suzuki.poulose@arm.com> To: linux-arm-kernel@lists.infradead.org Cc: mark.rutland@arm.com, ard.biesheuvel@linaro.org, maz@kernel.org, Suzuki K Poulose <suzuki.poulose@arm.com>, linux-kernel@vger.kernel.org, christoffer.dall@arm.com, catalin.marinas@arm.com, will@kernel.org, dave.martin@arm.com Subject: [PATCH v2 0/7] arm64: Fix support for no FP/SIMD Date: Tue, 17 Dec 2019 18:33:55 +0000 [thread overview] Message-ID: <20191217183402.2259904-1-suzuki.poulose@arm.com> (raw) 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 v5.5-rc2. 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/mmu.h | 2 +- arch/arm64/include/asm/simd.h | 8 +++- arch/arm64/kernel/cpufeature.c | 65 +++++++++++++++++++---------- arch/arm64/kernel/fpsimd.c | 32 ++++++++++++-- arch/arm64/kernel/process.c | 2 +- arch/arm64/kernel/ptrace.c | 12 ++++++ arch/arm64/kernel/signal.c | 17 +++++++- arch/arm64/kernel/signal32.c | 12 +++++- arch/arm64/kvm/hyp/switch.c | 9 ++++ 11 files changed, 132 insertions(+), 34 deletions(-) -- 2.23.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-12-17 18:34 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-17 18:33 Suzuki K Poulose [this message] 2019-12-17 18:33 ` [PATCH v2 0/7] arm64: Fix support for no FP/SIMD Suzuki K Poulose 2019-12-17 18:33 ` [PATCH v2 1/7] arm64: Introduce system_capabilities_finalized() marker Suzuki K Poulose 2019-12-17 18:33 ` Suzuki K Poulose 2020-01-10 14:50 ` Catalin Marinas 2020-01-10 14:50 ` Catalin Marinas 2019-12-17 18:33 ` [PATCH v2 2/7] arm64: fpsimd: Make sure SVE setup is complete before SIMD is used Suzuki K Poulose 2019-12-17 18:33 ` Suzuki K Poulose 2020-01-10 11:51 ` Catalin Marinas 2020-01-10 11:51 ` Catalin Marinas 2020-01-10 18:41 ` Suzuki Kuruppassery Poulose 2020-01-10 18:41 ` Suzuki Kuruppassery Poulose 2019-12-17 18:33 ` [PATCH v2 3/7] arm64: cpufeature: Fix the type of no FP/SIMD capability Suzuki K Poulose 2019-12-17 18:33 ` Suzuki K Poulose 2020-01-10 14:50 ` Catalin Marinas 2020-01-10 14:50 ` Catalin Marinas 2019-12-17 18:33 ` [PATCH v2 4/7] arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly Suzuki K Poulose 2019-12-17 18:33 ` Suzuki K Poulose 2020-01-10 14:51 ` Catalin Marinas 2020-01-10 14:51 ` Catalin Marinas 2019-12-17 18:34 ` [PATCH v2 5/7] arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations Suzuki K Poulose 2019-12-17 18:34 ` Suzuki K Poulose 2020-01-10 15:12 ` Catalin Marinas 2020-01-10 15:12 ` Catalin Marinas 2020-01-10 18:42 ` Suzuki Kuruppassery Poulose 2020-01-10 18:42 ` Suzuki Kuruppassery Poulose 2019-12-17 18:34 ` [PATCH v2 6/7] arm64: signal: nofpsimd: Handle fp/simd context for signal frames Suzuki K Poulose 2019-12-17 18:34 ` Suzuki K Poulose 2020-01-10 12:34 ` Catalin Marinas 2020-01-10 12:34 ` Catalin Marinas 2019-12-17 18:34 ` [PATCH v2 7/7] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly Suzuki K Poulose 2019-12-17 18:34 ` Suzuki K Poulose 2019-12-17 19:05 ` Marc Zyngier 2019-12-17 19:05 ` Marc Zyngier 2019-12-18 11:42 ` Suzuki Kuruppassery Poulose 2019-12-18 11:42 ` Suzuki Kuruppassery Poulose 2019-12-18 11:56 ` Marc Zyngier 2019-12-18 11:56 ` Marc Zyngier 2019-12-18 12:00 ` Suzuki Kuruppassery Poulose 2019-12-18 12:00 ` Suzuki Kuruppassery Poulose 2020-01-10 15:21 ` Marc Zyngier 2020-01-10 15:21 ` Marc Zyngier 2020-01-13 10:28 ` Suzuki Kuruppassery Poulose 2020-01-13 10:28 ` Suzuki Kuruppassery Poulose 2020-01-10 14:49 ` Catalin Marinas 2020-01-10 14:49 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191217183402.2259904-1-suzuki.poulose@arm.com \ --to=suzuki.poulose@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=christoffer.dall@arm.com \ --cc=dave.martin@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.