arm64: Generate cpucaps.h
PATCH 1/1 arm64: Generate cpucaps.h
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
As part of doing this we also do the Kbuild hookup required to hook up an arch tools directory and to generate header files in there.
This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing. Due to the UAO cpucap having been removed in the past we end up with ARM64_NCAPS being 1 smaller than it was before.
--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++ 6 files changed, 132 insertions(+), 74 deletions(-) delete mode 100644 arch/arm64/include/asm/cpucaps.h create mode 100644 arch/arm64/tools/Makefile create mode 100644 arch/arm64/tools/cpucaps create mode 100755 arch/arm64/tools/gen-cpucaps.awk
arch/arm64/Makefile +3 -0
@@ -175,6 +175,9 @@ vdso_install: $(if $(CONFIG_COMPAT_VDSO), \ $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 $@) +archprepare: + $(Q)$(MAKE) $(build)=arch/arm64/tools kapi + # We use MRPROPER_FILES and CLEAN_FILES now archclean: $(Q)$(MAKE) $(clean)=$(boot)
arch/arm64/include/asm/Kbuild +2 -0
@@ -4,3 +4,5 @@ generic-y += mcs_spinlock.h generic-y += qrwlock.h generic-y += qspinlock.h generic-y += user.h + +generated-y += cpucaps.h
arch/arm64/include/asm/cpucaps.h deleted +0 -74
74 lines not on this page · raw message
arch/arm64/tools/Makefile new file +22 -0
@@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 + +gen := arch/$(ARCH)/include/generated +kapi := $(gen)/asm + +kapi-hdrs-y := $(kapi)/cpucaps.h + +targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y)) + +PHONY += kapi + +kapi: $(kapi-hdrs-y) $(gen-y) + +# Create output directory if not already present +_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') + +quiet_cmd_gen_cpucaps = GEN $@ + cmd_gen_cpucaps = mkdir -p $(dir $@) && \ + $(AWK) -f $(filter-out $(PHONY),$^) > $@ + +$(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE + $(call if_changed,gen_cpucaps)
arch/arm64/tools/cpucaps new file +65 -0
65 lines not on this page · raw message
arch/arm64/tools/gen-cpucaps.awk new file +40 -0
@@ -0,0 +1,40 @@ +#!/bin/awk -f +# SPDX-License-Identifier: GPL-2.0 +# gen-cpucaps.awk: arm64 cpucaps header generator +# +# Usage: awk -f gen-cpucaps.awk cpucaps.txt + +# Log an error and terminate +function fatal(msg) { + print "Error at line " NR ": " msg > "/dev/stderr" + exit 1 +} + +# skip blank lines and comment lines +/^$/ { next } +/^#/ { next } + +BEGIN { + print "#ifndef __ASM_CPUCAPS_H" + print "#define __ASM_CPUCAPS_H" + print "" + print "/* Generated file - do not edit */" + cap_num = 0 + print "" +} + +/^[vA-Z0-9_]+$/ { + printf("#define ARM64_%-30s\t%d\n", $0, cap_num++) + next +} + +END { + printf("#define ARM64_NCAPS\t\t\t\t%d\n", cap_num) + print "" + print "#endif" +} + +# Any lines not handled by previous rules are unexpected +{ + fatal("unhandled statement") +}
Signature · 7 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Catalin Marinas
maintainerQuoted 18 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
As part of doing this we also do the
Kbuildhookup required to hook up an arch tools directory and to generate header files in there.This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing. Due to the UAO cpucap having been removed in the past we end up with
ARM64_NCAPSbeing 1 smaller than it was before.Signed-off-by Mark Brown <[email protected]>
Quoted 12 lines
--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++ 6 files changed, 132 insertions(+), 74 deletions(-) delete mode 100644 arch/arm64/include/asm/cpucaps.h create mode 100644 arch/arm64/tools/Makefile create mode 100644 arch/arm64/tools/cpucaps create mode 100755 arch/arm64/tools/gen-cpucaps.awk
It's a good cleanup, it saves us from always sorting out conflicts around ARM64_NCAPS. I'll either take it during the merging window with the for-next/fixes folded in or push it at -rc1 as there's a change in cpucaps.h not currently in for-next/core.
Thanks.
Signature · 6 lines
Catalin _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 10 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
As part of doing this we also do the
Kbuildhookup required to hook up an arch tools directory and to generate header files in there.
Quoted 8 lines
This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing. Due to the UAO cpucap having been removed in the past we end up with
ARM64_NCAPSbeing 1 smaller than it was before.Signed-off-by Mark Brown <[email protected]>
Neat! This looks good to me per my understanding of awk.
I have this s quick spin, and tested and out-of-tree build and common awk implementations (gawk, mawk, nawk), and everything worked as expected. So FWIW:
Thanks,
Mark.
Quoted 270 lines
--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++ 6 files changed, 132 insertions(+), 74 deletions(-) delete mode 100644 arch/arm64/include/asm/cpucaps.h create mode 100644 arch/arm64/tools/Makefile create mode 100644 arch/arm64/tools/cpucaps create mode 100755 arch/arm64/tools/gen-cpucaps.awkarch/arm64/Makefile +3
-0@@ -175,6 +175,9 @@ vdso_install: $(if $(CONFIG_COMPAT_VDSO), \ $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 $@) +archprepare: + $(Q)$(MAKE) $(build)=arch/arm64/tools kapi + # We use MRPROPER_FILES and CLEAN_FILES now archclean: $(Q)$(MAKE) $(clean)=$(boot)arch/arm64/include/asm/Kbuild +2
-0@@ -4,3 +4,5 @@ generic-y += mcs_spinlock.h generic-y += qrwlock.h generic-y += qspinlock.h generic-y += user.h + +generated-y += cpucaps.harch/arm64/include/asm/cpucaps.h deleted +0
-74@@ -1,74 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* -* arch/arm64/include/asm/cpucaps.h -* -* Copyright (C) 2016 ARM Ltd. -*/ -#ifndef __ASM_CPUCAPS_H -#define __ASM_CPUCAPS_H - -#define ARM64_WORKAROUND_CLEAN_CACHE 0 -#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1 -#define ARM64_WORKAROUND_845719 2 -#define ARM64_HAS_SYSREG_GIC_CPUIF 3 -#define ARM64_HAS_PAN 4 -#define ARM64_HAS_LSE_ATOMICS 5 -#define ARM64_WORKAROUND_CAVIUM_23154 6 -#define ARM64_WORKAROUND_834220 7 -#define ARM64_HAS_NO_HW_PREFETCH 8 -#define ARM64_HAS_VIRT_HOST_EXTN 11 -#define ARM64_WORKAROUND_CAVIUM_27456 12 -#define ARM64_HAS_32BIT_EL0 13 -#define ARM64_SPECTRE_V3A 14 -#define ARM64_HAS_CNP 15 -#define ARM64_HAS_NO_FPSIMD 16 -#define ARM64_WORKAROUND_REPEAT_TLBI 17 -#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 18 -#define ARM64_WORKAROUND_858921 19 -#define ARM64_WORKAROUND_CAVIUM_30115 20 -#define ARM64_HAS_DCPOP 21 -#define ARM64_SVE 22 -#define ARM64_UNMAP_KERNEL_AT_EL0 23 -#define ARM64_SPECTRE_V2 24 -#define ARM64_HAS_RAS_EXTN 25 -#define ARM64_WORKAROUND_843419 26 -#define ARM64_HAS_CACHE_IDC 27 -#define ARM64_HAS_CACHE_DIC 28 -#define ARM64_HW_DBM 29 -#define ARM64_SPECTRE_V4 30 -#define ARM64_MISMATCHED_CACHE_TYPE 31 -#define ARM64_HAS_STAGE2_FWB 32 -#define ARM64_HAS_CRC32 33 -#define ARM64_SSBS 34 -#define ARM64_WORKAROUND_1418040 35 -#define ARM64_HAS_SB 36 -#define ARM64_WORKAROUND_SPECULATIVE_AT 37 -#define ARM64_HAS_ADDRESS_AUTH_ARCH 38 -#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 39 -#define ARM64_HAS_GENERIC_AUTH_ARCH 40 -#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41 -#define ARM64_HAS_IRQ_PRIO_MASKING 42 -#define ARM64_HAS_DCPODP 43 -#define ARM64_WORKAROUND_1463225 44 -#define ARM64_WORKAROUND_CAVIUM_TX2_219_TVM 45 -#define ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM 46 -#define ARM64_WORKAROUND_1542419 47 -#define ARM64_HAS_E0PD 48 -#define ARM64_HAS_RNG 49 -#define ARM64_HAS_AMU_EXTN 50 -#define ARM64_HAS_ADDRESS_AUTH 51 -#define ARM64_HAS_GENERIC_AUTH 52 -#define ARM64_HAS_32BIT_EL1 53 -#define ARM64_BTI 54 -#define ARM64_HAS_ARMv8_4_TTL 55 -#define ARM64_HAS_TLB_RANGE 56 -#define ARM64_MTE 57 -#define ARM64_WORKAROUND_1508412 58 -#define ARM64_HAS_LDAPR 59 -#define ARM64_KVM_PROTECTED_MODE 60 -#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP 61 -#define ARM64_HAS_EPAN 62 - -#define ARM64_NCAPS 63 - -#endif /* __ASM_CPUCAPS_H */ arch/arm64/tools/Makefile new file +22
-0@@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 + +gen := arch/$(ARCH)/include/generated +kapi := $(gen)/asm + +kapi-hdrs-y := $(kapi)/cpucaps.h + +targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y)) + +PHONY += kapi + +kapi: $(kapi-hdrs-y) $(gen-y) + +# Create output directory if not already present +_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') + +quiet_cmd_gen_cpucaps = GEN $@ + cmd_gen_cpucaps = mkdir -p $(dir $@) && \ + $(AWK) -f $(filter-out $(PHONY),$^) > $@ + +$(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE + $(call if_changed,gen_cpucaps)arch/arm64/tools/cpucaps new file +65
-0@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Internal CPU capabilities constants, keep this list sorted + +BTI +HAS_32BIT_EL0 +HAS_32BIT_EL1 +HAS_ADDRESS_AUTH +HAS_ADDRESS_AUTH_ARCH +HAS_ADDRESS_AUTH_IMP_DEF +HAS_AMU_EXTN +HAS_ARMv8_4_TTL +HAS_CACHE_DIC +HAS_CACHE_IDC +HAS_CNP +HAS_CRC32 +HAS_DCPODP +HAS_DCPOP +HAS_E0PD +HAS_EPAN +HAS_GENERIC_AUTH +HAS_GENERIC_AUTH_ARCH +HAS_GENERIC_AUTH_IMP_DEF +HAS_IRQ_PRIO_MASKING +HAS_LDAPR +HAS_LSE_ATOMICS +HAS_NO_FPSIMD +HAS_NO_HW_PREFETCH +HAS_PAN +HAS_RAS_EXTN +HAS_RNG +HAS_SB +HAS_STAGE2_FWB +HAS_SYSREG_GIC_CPUIF +HAS_TLB_RANGE +HAS_VIRT_HOST_EXTN +HW_DBM +KVM_PROTECTED_MODE +MISMATCHED_CACHE_TYPE +MTE +SPECTRE_V2 +SPECTRE_V3A +SPECTRE_V4 +SSBS +SVE +UNMAP_KERNEL_AT_EL0 +WORKAROUND_834220 +WORKAROUND_843419 +WORKAROUND_845719 +WORKAROUND_858921 +WORKAROUND_1418040 +WORKAROUND_1463225 +WORKAROUND_1508412 +WORKAROUND_1542419 +WORKAROUND_CAVIUM_23154 +WORKAROUND_CAVIUM_27456 +WORKAROUND_CAVIUM_30115 +WORKAROUND_CAVIUM_TX2_219_PRFM +WORKAROUND_CAVIUM_TX2_219_TVM +WORKAROUND_CLEAN_CACHE +WORKAROUND_DEVICE_LOAD_ACQUIRE +WORKAROUND_NVIDIA_CARMEL_CNP +WORKAROUND_QCOM_FALKOR_E1003 +WORKAROUND_REPEAT_TLBI +WORKAROUND_SPECULATIVE_ATarch/arm64/tools/gen-cpucaps.awk new file +40
-0@@ -0,0 +1,40 @@ +#!/bin/awk -f +# SPDX-License-Identifier: GPL-2.0 +# gen-cpucaps.awk: arm64 cpucaps header generator +# +# Usage: awk -f gen-cpucaps.awk cpucaps.txt + +# Log an error and terminate +function fatal(msg) { + print "Error at line " NR ": " msg > "/dev/stderr" + exit 1 +} + +# skip blank lines and comment lines +/^$/ { next } +/^#/ { next } + +BEGIN { + print "#ifndef __ASM_CPUCAPS_H" + print "#define __ASM_CPUCAPS_H" + print "" + print "/* Generated file - do not edit */" + cap_num = 0 + print "" +} + +/^[vA-Z0-9_]+$/ { + printf("#define ARM64_%-30s\t%d\n", $0, cap_num++) + next +} + +END { + printf("#define ARM64_NCAPS\t\t\t\t%d\n", cap_num) + print "" + print "#endif" +} + +# Any lines not handled by previous rules are unexpected +{ + fatal("unhandled statement") +}Signature · 7 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 8 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
[...]
Applied to arm64 (for-next/fixes), thanks! While not actually a fix, I'm merging it at -rc1 to avoid conflicts with changes to cpucaps.h during the merging window.
[1/1] arm64: Generate cpucaps.h
https://git.kernel.org/arm64/c/0c6c2d3615ef
Signature · 7 lines
Catalin _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 36 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
As part of doing this we also do the
Kbuildhookup required to hook up an arch tools directory and to generate header files in there.This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing. Due to the UAO cpucap having been removed in the past we end up with
ARM64_NCAPSbeing 1 smaller than it was before.Signed-off-by Mark Brown <[email protected]>--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++ 6 files changed, 132 insertions(+), 74 deletions(-) delete mode 100644 arch/arm64/include/asm/cpucaps.h create mode 100644 arch/arm64/tools/Makefile create mode 100644 arch/arm64/tools/cpucaps create mode 100755 arch/arm64/tools/gen-cpucaps.awkarch/arm64/Makefile +0
-0
arch/arm64/Makefile vdso_install: · line 179
Quoted 5 lines
arch/arm64/Makefile +2
-0@@ -175,6 +175,9 @@ vdso_install: $(if $(CONFIG_COMPAT_VDSO), \ $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 $@) +archprepare: + $(Q)$(MAKE) $(build)=arch/arm64/tools kapi
Small nit. So going forward this new directory (arch/arm64/tools/), will be used to hold similar scripts that generate header or similar things ? At first the directory name 'tool' was bit confusing but seems like other archs (arm, m68k, mips, powerpc, s390, sh) have this directory as well.
Quoted 215 lines
arch/arm64/Makefile +1
-0+ # We use MRPROPER_FILES and CLEAN_FILES now archclean: $(Q)$(MAKE) $(clean)=$(boot)arch/arm64/include/asm/Kbuild +2
-0@@ -4,3 +4,5 @@ generic-y += mcs_spinlock.h generic-y += qrwlock.h generic-y += qspinlock.h generic-y += user.h + +generated-y += cpucaps.harch/arm64/include/asm/cpucaps.h deleted +0
-74@@ -1,74 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* -* arch/arm64/include/asm/cpucaps.h -* -* Copyright (C) 2016 ARM Ltd. -*/ -#ifndef __ASM_CPUCAPS_H -#define __ASM_CPUCAPS_H - -#define ARM64_WORKAROUND_CLEAN_CACHE 0 -#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1 -#define ARM64_WORKAROUND_845719 2 -#define ARM64_HAS_SYSREG_GIC_CPUIF 3 -#define ARM64_HAS_PAN 4 -#define ARM64_HAS_LSE_ATOMICS 5 -#define ARM64_WORKAROUND_CAVIUM_23154 6 -#define ARM64_WORKAROUND_834220 7 -#define ARM64_HAS_NO_HW_PREFETCH 8 -#define ARM64_HAS_VIRT_HOST_EXTN 11 -#define ARM64_WORKAROUND_CAVIUM_27456 12 -#define ARM64_HAS_32BIT_EL0 13 -#define ARM64_SPECTRE_V3A 14 -#define ARM64_HAS_CNP 15 -#define ARM64_HAS_NO_FPSIMD 16 -#define ARM64_WORKAROUND_REPEAT_TLBI 17 -#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 18 -#define ARM64_WORKAROUND_858921 19 -#define ARM64_WORKAROUND_CAVIUM_30115 20 -#define ARM64_HAS_DCPOP 21 -#define ARM64_SVE 22 -#define ARM64_UNMAP_KERNEL_AT_EL0 23 -#define ARM64_SPECTRE_V2 24 -#define ARM64_HAS_RAS_EXTN 25 -#define ARM64_WORKAROUND_843419 26 -#define ARM64_HAS_CACHE_IDC 27 -#define ARM64_HAS_CACHE_DIC 28 -#define ARM64_HW_DBM 29 -#define ARM64_SPECTRE_V4 30 -#define ARM64_MISMATCHED_CACHE_TYPE 31 -#define ARM64_HAS_STAGE2_FWB 32 -#define ARM64_HAS_CRC32 33 -#define ARM64_SSBS 34 -#define ARM64_WORKAROUND_1418040 35 -#define ARM64_HAS_SB 36 -#define ARM64_WORKAROUND_SPECULATIVE_AT 37 -#define ARM64_HAS_ADDRESS_AUTH_ARCH 38 -#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 39 -#define ARM64_HAS_GENERIC_AUTH_ARCH 40 -#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41 -#define ARM64_HAS_IRQ_PRIO_MASKING 42 -#define ARM64_HAS_DCPODP 43 -#define ARM64_WORKAROUND_1463225 44 -#define ARM64_WORKAROUND_CAVIUM_TX2_219_TVM 45 -#define ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM 46 -#define ARM64_WORKAROUND_1542419 47 -#define ARM64_HAS_E0PD 48 -#define ARM64_HAS_RNG 49 -#define ARM64_HAS_AMU_EXTN 50 -#define ARM64_HAS_ADDRESS_AUTH 51 -#define ARM64_HAS_GENERIC_AUTH 52 -#define ARM64_HAS_32BIT_EL1 53 -#define ARM64_BTI 54 -#define ARM64_HAS_ARMv8_4_TTL 55 -#define ARM64_HAS_TLB_RANGE 56 -#define ARM64_MTE 57 -#define ARM64_WORKAROUND_1508412 58 -#define ARM64_HAS_LDAPR 59 -#define ARM64_KVM_PROTECTED_MODE 60 -#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP 61 -#define ARM64_HAS_EPAN 62 - -#define ARM64_NCAPS 63 - -#endif /* __ASM_CPUCAPS_H */ arch/arm64/tools/Makefile new file +22
-0@@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 + +gen := arch/$(ARCH)/include/generated +kapi := $(gen)/asm + +kapi-hdrs-y := $(kapi)/cpucaps.h + +targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y)) + +PHONY += kapi + +kapi: $(kapi-hdrs-y) $(gen-y) + +# Create output directory if not already present +_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') + +quiet_cmd_gen_cpucaps = GEN $@ + cmd_gen_cpucaps = mkdir -p $(dir $@) && \ + $(AWK) -f $(filter-out $(PHONY),$^) > $@ + +$(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE + $(call if_changed,gen_cpucaps)arch/arm64/tools/cpucaps new file +65
-0@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Internal CPU capabilities constants, keep this list sorted + +BTI +HAS_32BIT_EL0 +HAS_32BIT_EL1 +HAS_ADDRESS_AUTH +HAS_ADDRESS_AUTH_ARCH +HAS_ADDRESS_AUTH_IMP_DEF +HAS_AMU_EXTN +HAS_ARMv8_4_TTL +HAS_CACHE_DIC +HAS_CACHE_IDC +HAS_CNP +HAS_CRC32 +HAS_DCPODP +HAS_DCPOP +HAS_E0PD +HAS_EPAN +HAS_GENERIC_AUTH +HAS_GENERIC_AUTH_ARCH +HAS_GENERIC_AUTH_IMP_DEF +HAS_IRQ_PRIO_MASKING +HAS_LDAPR +HAS_LSE_ATOMICS +HAS_NO_FPSIMD +HAS_NO_HW_PREFETCH +HAS_PAN +HAS_RAS_EXTN +HAS_RNG +HAS_SB +HAS_STAGE2_FWB +HAS_SYSREG_GIC_CPUIF +HAS_TLB_RANGE +HAS_VIRT_HOST_EXTN +HW_DBM +KVM_PROTECTED_MODE +MISMATCHED_CACHE_TYPE +MTE +SPECTRE_V2 +SPECTRE_V3A +SPECTRE_V4 +SSBS +SVE +UNMAP_KERNEL_AT_EL0 +WORKAROUND_834220 +WORKAROUND_843419 +WORKAROUND_845719 +WORKAROUND_858921 +WORKAROUND_1418040 +WORKAROUND_1463225 +WORKAROUND_1508412 +WORKAROUND_1542419 +WORKAROUND_CAVIUM_23154 +WORKAROUND_CAVIUM_27456 +WORKAROUND_CAVIUM_30115 +WORKAROUND_CAVIUM_TX2_219_PRFM +WORKAROUND_CAVIUM_TX2_219_TVM +WORKAROUND_CLEAN_CACHE +WORKAROUND_DEVICE_LOAD_ACQUIRE +WORKAROUND_NVIDIA_CARMEL_CNP +WORKAROUND_QCOM_FALKOR_E1003 +WORKAROUND_REPEAT_TLBI +WORKAROUND_SPECULATIVE_ATarch/arm64/tools/gen-cpucaps.awk new file +16
-0@@ -0,0 +1,40 @@ +#!/bin/awk -f +# SPDX-License-Identifier: GPL-2.0 +# gen-cpucaps.awk: arm64 cpucaps header generator +# +# Usage: awk -f gen-cpucaps.awk cpucaps.txt + +# Log an error and terminate +function fatal(msg) { + print "Error at line " NR ": " msg > "/dev/stderr" + exit 1 +} + +# skip blank lines and comment lines +/^$/ { next } +/^#/ { next } +
arch/arm64/tools/gen-cpucaps.awk line 26
Quoted 10 lines
arch/arm64/tools/gen-cpucaps.awk new file +10
-0+BEGIN { + print "#ifndef __ASM_CPUCAPS_H" + print "#define __ASM_CPUCAPS_H" + print "" + print "/* Generated file - do not edit */" + cap_num = 0 + print "" +} + +/^[vA-Z0-9_]+$/ {
Small nit. Should this be length restricted at the least ? Like each CAP entries should not exceed a certain length.
arch/arm64/tools/gen-cpucaps.awk line 34
Quoted 8 lines
arch/arm64/tools/gen-cpucaps.awk new file +8
-0+ printf("#define ARM64_%-30s\t%d\n", $0, cap_num++) + next +} + +END { + printf("#define ARM64_NCAPS\t\t\t\t%d\n", cap_num) + print "" + print "#endif"
Small nit. Should it be print "#endif /* __ASM_CPUCAPS_H */" instead in order to be complete.
arch/arm64/tools/gen-cpucaps.awk line 40
Quoted 7 lines
arch/arm64/tools/gen-cpucaps.awk new file +6
-0+} + +# Any lines not handled by previous rules are unexpected +{ + fatal("unhandled statement") +}
Did not see any problem with the patch after using it with multiple 'awk' implementations. FWIW, with/without changes requested earlier.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Mark Rutland
reviewerQuoted 41 lines · Anshuman Khandual
Quoted 39 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
As part of doing this we also do the
Kbuildhookup required to hook up an arch tools directory and to generate header files in there.This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing. Due to the UAO cpucap having been removed in the past we end up with
ARM64_NCAPSbeing 1 smaller than it was before.Signed-off-by Mark Brown <[email protected]>--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++ 6 files changed, 132 insertions(+), 74 deletions(-) delete mode 100644 arch/arm64/include/asm/cpucaps.h create mode 100644 arch/arm64/tools/Makefile create mode 100644 arch/arm64/tools/cpucaps create mode 100755 arch/arm64/tools/gen-cpucaps.awkarch/arm64/Makefile +0
-0@@ -175,6 +175,9 @@ vdso_install: $(if $(CONFIG_COMPAT_VDSO), \ $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 $@)
Quoted 7 lines
arch/arm64/Makefile vdso_install: · line 179
Quoted 2 lines
arch/arm64/Makefile +2
-0+archprepare: + $(Q)$(MAKE) $(build)=arch/arm64/tools kapiSmall nit. So going forward this new directory (
arch/arm64/tools/), will be used to hold similar scripts that generate header or similar things ? At first the directory name 'tool' was bit confusing but seems like other archs (arm, m68k, mips, powerpc, s390, sh) have this directory as well.
Yup; there's more stuff we might want to put here in future, e.g.
* Generation of (or consistency-checks) for the kernel HWCAP glue
* Generation of the sysreg headers
* Generation of the insn code
* Generation of metadata (or consistency checks) for RELIABLE_STACKTRACE, LIVEPATCH, etc
[...]
Quoted 5 lines
Quoted 5 lines
arch/arm64/Makefile +5
-0+BEGIN { + print "#ifndef __ASM_CPUCAPS_H" + print "#define __ASM_CPUCAPS_H" + print "" + print "/* Generated file - do not edit */"
Quoted 8 lines
arch/arm64/Makefile
Quoted 5 lines
arch/arm64/Makefile +5
-0+ cap_num = 0 + print "" +} + +/^[vA-Z0-9_]+$/ {Small nit. Should this be length restricted at the least ? Like each CAP entries should not exceed a certain length.
I don't think we should enforce a length limit in the script, as we'd have to select an arbitrary limit, and given we should catch exceedingly long names during review, I think it's more likely to be a hindrance than a help (e.g. if we ever bump up against that limit).
Quoted 11 lines
arch/arm64/Makefile
Quoted 8 lines
arch/arm64/Makefile +8
-0+ printf("#define ARM64_%-30s\t%d\n", $0, cap_num++) + next +} + +END { + printf("#define ARM64_NCAPS\t\t\t\t%d\n", cap_num) + print "" + print "#endif"Small nit. Should it be print "#endif /*
__ASM_CPUCAPS_H*/" instead in order to be complete.
Agreed; that would be nice.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 2 lines · Anshuman Khandual
Small nit. So going forward this new directory (
arch/arm64/tools/), will be used to hold similar scripts that generate header or similar things ?
Yes, anything we need to run in the build process. Some of the other architectures have some tools to verify generated binaries have particular properties as well for example.
Quoted 2 lines
At first the directory name 'tool' was bit confusing but seems like other archs (arm, m68k, mips, powerpc, s390, sh) have this directory as well.
Yes, it's the standard pattern.
Quoted 4 lines
Quoted 1 line
+/^[vA-Z0-9_]+$/ {
Small nit. Should this be length restricted at the least ? Like each CAP entries should not exceed a certain length.
If you want to send a patch by all means, I don't think it's useful though - it doesn't matter to the software and the main issue is taste which is going to get considered regardless of what software says, if people are happy with an identifer that hits some limit they're just going to raise the limit.
Quoted 2 lines
Small nit. Should it be print "#endif /*
__ASM_CPUCAPS_H*/" instead in order to be complete.
I guess. Given that this is merged that'd need to be an incremental patch.
Please delete unneeded context from mails when replying. Doing this makes it much easier to find your reply in the message, helping ensure it won't be missed by people scrolling through the irrelevant quoted material.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Mark,
Quoted 17 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
As part of doing this we also do the
Kbuildhookup required to hook up an arch tools directory and to generate header files in there.This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing. Due to the UAO cpucap having been removed in the past we end up with
ARM64_NCAPSbeing 1 smaller than it was before.
Quoted 8 lines
Signed-off-by Mark Brown <[email protected]>--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++
I guess the reason you're doing it like this, and not using a simple C enum, is that some of these definitions are used from asm files? Do we use similar mechanisms in other places?
Would introducing a generic way to generate headers with definitions from a C enum be worthwhile?
Gr{oetje,eeting}s,
Geert
Signature · 10 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 2 lines · Geert Uytterhoeven
I guess the reason you're doing it like this, and not using a simple C enum, is that some of these definitions are used from asm files?
Yes, there's references in asm files.
Quoted 1 line
Do we use similar mechanisms in other places?
I'd be surprised if we weren't, though off the top of my head the other examples in arm64 are the sysregs and the hwcaps which are both ABI and don't really benefit in the same way.
Quoted 2 lines
Would introducing a generic way to generate headers with definitions from a C enum be worthwhile?
There must be some other arch which could use one at least.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 6 lines · Mark Brown
The arm64 code allocates an internal constant to every CPU feature it can detect, distinct from the public hwcap numbers we use to expose some features to userspace. Currently this is maintained manually which is an irritating source of conflicts when working on new features, to avoid this replace the header with a simple text file listing the names we've assigned and sort it to minimise conflicts.
Thanks for doing this Mark, speaking as someone who has had to backport a lot of these patches to a distro kernel :)
Quoted 8 lines
As part of doing this we also do the
Kbuildhookup required to hook up an arch tools directory and to generate header files in there.This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing.
Unfortunately I believe I've hit a regression[*] due to such an ordering dependency. UNMAP_KERNEL_AT_EL0 currently needs to be processed after WORKAROUND_CAVIUM_27456. ThunderX systems are incompatible with KPTI, so unmap_kernel_at_el0() bails if WORKAROUND_CAVIUM_27456 is set. Because of the sorting, WORKAROUND_CAVIUM_27456 will not yet have been considered when unmap_kernel_at_el0() checks for it, so the kernel tries to run w/ KPTI - and quickly falls over.
I've verified that reordering cpucaps to move WORKAROUND_CAVIUM_27456 just above UNMAP_KERNEL_AT_EL0 restores the old behavior. I'm not sure of the right way to address this - perhaps unmap_kernel_at_el0() could check cavium_erratum_27456_cpus[] directly instead of keying on the ARM64_WORKAROUND_CAVIUM_27456 cap?
-dann
[*] https://bugs.launchpad.net/bugs/1942633
Quoted 256 lines
Due to the UAO cpucap having been removed in
the past we end up withARM64_NCAPSbeing 1 smaller than it was before.Signed-off-by Mark Brown <[email protected]>--- arch/arm64/Makefile | 3 ++ arch/arm64/include/asm/Kbuild | 2 + arch/arm64/include/asm/cpucaps.h | 74 -------------------------------- arch/arm64/tools/Makefile | 22 ++++++++++ arch/arm64/tools/cpucaps | 65 ++++++++++++++++++++++++++++ arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++ 6 files changed, 132 insertions(+), 74 deletions(-) delete mode 100644 arch/arm64/include/asm/cpucaps.h create mode 100644 arch/arm64/tools/Makefile create mode 100644 arch/arm64/tools/cpucaps create mode 100755 arch/arm64/tools/gen-cpucaps.awkarch/arm64/Makefile +3
-0@@ -175,6 +175,9 @@ vdso_install: $(if $(CONFIG_COMPAT_VDSO), \ $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 $@) +archprepare: + $(Q)$(MAKE) $(build)=arch/arm64/tools kapi + # We use MRPROPER_FILES and CLEAN_FILES now archclean: $(Q)$(MAKE) $(clean)=$(boot)arch/arm64/include/asm/Kbuild +2
-0@@ -4,3 +4,5 @@ generic-y += mcs_spinlock.h generic-y += qrwlock.h generic-y += qspinlock.h generic-y += user.h + +generated-y += cpucaps.harch/arm64/include/asm/cpucaps.h deleted +0
-74@@ -1,74 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* -* arch/arm64/include/asm/cpucaps.h -* -* Copyright (C) 2016 ARM Ltd. -*/ -#ifndef __ASM_CPUCAPS_H -#define __ASM_CPUCAPS_H - -#define ARM64_WORKAROUND_CLEAN_CACHE 0 -#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1 -#define ARM64_WORKAROUND_845719 2 -#define ARM64_HAS_SYSREG_GIC_CPUIF 3 -#define ARM64_HAS_PAN 4 -#define ARM64_HAS_LSE_ATOMICS 5 -#define ARM64_WORKAROUND_CAVIUM_23154 6 -#define ARM64_WORKAROUND_834220 7 -#define ARM64_HAS_NO_HW_PREFETCH 8 -#define ARM64_HAS_VIRT_HOST_EXTN 11 -#define ARM64_WORKAROUND_CAVIUM_27456 12 -#define ARM64_HAS_32BIT_EL0 13 -#define ARM64_SPECTRE_V3A 14 -#define ARM64_HAS_CNP 15 -#define ARM64_HAS_NO_FPSIMD 16 -#define ARM64_WORKAROUND_REPEAT_TLBI 17 -#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 18 -#define ARM64_WORKAROUND_858921 19 -#define ARM64_WORKAROUND_CAVIUM_30115 20 -#define ARM64_HAS_DCPOP 21 -#define ARM64_SVE 22 -#define ARM64_UNMAP_KERNEL_AT_EL0 23 -#define ARM64_SPECTRE_V2 24 -#define ARM64_HAS_RAS_EXTN 25 -#define ARM64_WORKAROUND_843419 26 -#define ARM64_HAS_CACHE_IDC 27 -#define ARM64_HAS_CACHE_DIC 28 -#define ARM64_HW_DBM 29 -#define ARM64_SPECTRE_V4 30 -#define ARM64_MISMATCHED_CACHE_TYPE 31 -#define ARM64_HAS_STAGE2_FWB 32 -#define ARM64_HAS_CRC32 33 -#define ARM64_SSBS 34 -#define ARM64_WORKAROUND_1418040 35 -#define ARM64_HAS_SB 36 -#define ARM64_WORKAROUND_SPECULATIVE_AT 37 -#define ARM64_HAS_ADDRESS_AUTH_ARCH 38 -#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 39 -#define ARM64_HAS_GENERIC_AUTH_ARCH 40 -#define ARM64_HAS_GENERIC_AUTH_IMP_DEF 41 -#define ARM64_HAS_IRQ_PRIO_MASKING 42 -#define ARM64_HAS_DCPODP 43 -#define ARM64_WORKAROUND_1463225 44 -#define ARM64_WORKAROUND_CAVIUM_TX2_219_TVM 45 -#define ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM 46 -#define ARM64_WORKAROUND_1542419 47 -#define ARM64_HAS_E0PD 48 -#define ARM64_HAS_RNG 49 -#define ARM64_HAS_AMU_EXTN 50 -#define ARM64_HAS_ADDRESS_AUTH 51 -#define ARM64_HAS_GENERIC_AUTH 52 -#define ARM64_HAS_32BIT_EL1 53 -#define ARM64_BTI 54 -#define ARM64_HAS_ARMv8_4_TTL 55 -#define ARM64_HAS_TLB_RANGE 56 -#define ARM64_MTE 57 -#define ARM64_WORKAROUND_1508412 58 -#define ARM64_HAS_LDAPR 59 -#define ARM64_KVM_PROTECTED_MODE 60 -#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP 61 -#define ARM64_HAS_EPAN 62 - -#define ARM64_NCAPS 63 - -#endif /* __ASM_CPUCAPS_H */ arch/arm64/tools/Makefile new file +22
-0@@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 + +gen := arch/$(ARCH)/include/generated +kapi := $(gen)/asm + +kapi-hdrs-y := $(kapi)/cpucaps.h + +targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y)) + +PHONY += kapi + +kapi: $(kapi-hdrs-y) $(gen-y) + +# Create output directory if not already present +_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') + +quiet_cmd_gen_cpucaps = GEN $@ + cmd_gen_cpucaps = mkdir -p $(dir $@) && \ + $(AWK) -f $(filter-out $(PHONY),$^) > $@ + +$(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE + $(call if_changed,gen_cpucaps)arch/arm64/tools/cpucaps new file +65
-0@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Internal CPU capabilities constants, keep this list sorted + +BTI +HAS_32BIT_EL0 +HAS_32BIT_EL1 +HAS_ADDRESS_AUTH +HAS_ADDRESS_AUTH_ARCH +HAS_ADDRESS_AUTH_IMP_DEF +HAS_AMU_EXTN +HAS_ARMv8_4_TTL +HAS_CACHE_DIC +HAS_CACHE_IDC +HAS_CNP +HAS_CRC32 +HAS_DCPODP +HAS_DCPOP +HAS_E0PD +HAS_EPAN +HAS_GENERIC_AUTH +HAS_GENERIC_AUTH_ARCH +HAS_GENERIC_AUTH_IMP_DEF +HAS_IRQ_PRIO_MASKING +HAS_LDAPR +HAS_LSE_ATOMICS +HAS_NO_FPSIMD +HAS_NO_HW_PREFETCH +HAS_PAN +HAS_RAS_EXTN +HAS_RNG +HAS_SB +HAS_STAGE2_FWB +HAS_SYSREG_GIC_CPUIF +HAS_TLB_RANGE +HAS_VIRT_HOST_EXTN +HW_DBM +KVM_PROTECTED_MODE +MISMATCHED_CACHE_TYPE +MTE +SPECTRE_V2 +SPECTRE_V3A +SPECTRE_V4 +SSBS +SVE +UNMAP_KERNEL_AT_EL0 +WORKAROUND_834220 +WORKAROUND_843419 +WORKAROUND_845719 +WORKAROUND_858921 +WORKAROUND_1418040 +WORKAROUND_1463225 +WORKAROUND_1508412 +WORKAROUND_1542419 +WORKAROUND_CAVIUM_23154 +WORKAROUND_CAVIUM_27456 +WORKAROUND_CAVIUM_30115 +WORKAROUND_CAVIUM_TX2_219_PRFM +WORKAROUND_CAVIUM_TX2_219_TVM +WORKAROUND_CLEAN_CACHE +WORKAROUND_DEVICE_LOAD_ACQUIRE +WORKAROUND_NVIDIA_CARMEL_CNP +WORKAROUND_QCOM_FALKOR_E1003 +WORKAROUND_REPEAT_TLBI +WORKAROUND_SPECULATIVE_ATarch/arm64/tools/gen-cpucaps.awk new file +30
-0@@ -0,0 +1,40 @@ +#!/bin/awk -f +# SPDX-License-Identifier: GPL-2.0 +# gen-cpucaps.awk: arm64 cpucaps header generator +# +# Usage: awk -f gen-cpucaps.awk cpucaps.txt + +# Log an error and terminate +function fatal(msg) { + print "Error at line " NR ": " msg > "/dev/stderr" + exit 1 +} + +# skip blank lines and comment lines +/^$/ { next } +/^#/ { next } + +BEGIN { + print "#ifndef __ASM_CPUCAPS_H" + print "#define __ASM_CPUCAPS_H" + print "" + print "/* Generated file - do not edit */" + cap_num = 0 + print "" +} + +/^[vA-Z0-9_]+$/ { + printf("#define ARM64_%-30s\t%d\n", $0, cap_num++) + next +} +
arch/arm64/tools/gen-cpucaps.awk line 40
Quoted 10 lines
arch/arm64/tools/gen-cpucaps.awk new file +10
-0+END { + printf("#define ARM64_NCAPS\t\t\t\t%d\n", cap_num) + print "" + print "#endif" +} + +# Any lines not handled by previous rules are unexpected +{ + fatal("unhandled statement") +}
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 17 lines · dann frazier
Quoted 5 lines · Mark Brown
This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing.
Unfortunately I believe I've hit a regression[*] due to such an ordering dependency.
UNMAP_KERNEL_AT_EL0currently needs to be processed afterWORKAROUND_CAVIUM_27456. ThunderX systems are incompatible with KPTI, sounmap_kernel_at_el0()bails ifWORKAROUND_CAVIUM_27456is set. Because of the sorting,WORKAROUND_CAVIUM_27456will not yet have been considered whenunmap_kernel_at_el0()checks for it, so the kernel tries to run w/ KPTI - and quickly falls over.
Quoted 5 lines
I've verified that reordering cpucaps to move
WORKAROUND_CAVIUM_27456just aboveUNMAP_KERNEL_AT_EL0restores the old behavior. I'm not sure of the right way to address this - perhapsunmap_kernel_at_el0()could check cavium_erratum_27456_cpus[] directly instead of keying on theARM64_WORKAROUND_CAVIUM_27456cap?
Ugh, right. Another option would be to do something like rename to CAVIUM_WORKAROUND_27456 which would be inconsistent naming and but would sort things in a way that gets the checks to run in the order we're relying on but either works for me. Neither is great.
It'd be really good to get more coverage of the enterprise systems in KernelCI or similar so we can catch issues like this more easily.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 18 lines · Mark Brown
Quoted 16 lines · dann frazier
Quoted 5 lines · Mark Brown
This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing.
Unfortunately I believe I've hit a regression[*] due to such an ordering dependency.
UNMAP_KERNEL_AT_EL0currently needs to be processed afterWORKAROUND_CAVIUM_27456. ThunderX systems are incompatible with KPTI, sounmap_kernel_at_el0()bails ifWORKAROUND_CAVIUM_27456is set. Because of the sorting,WORKAROUND_CAVIUM_27456will not yet have been considered whenunmap_kernel_at_el0()checks for it, so the kernel tries to run w/ KPTI - and quickly falls over.
Quoted 5 lines
Quoted 5 lines
I've verified that reordering cpucaps to move
WORKAROUND_CAVIUM_27456just aboveUNMAP_KERNEL_AT_EL0restores the old behavior. I'm not sure of the right way to address this - perhapsunmap_kernel_at_el0()could check cavium_erratum_27456_cpus[] directly instead of keying on theARM64_WORKAROUND_CAVIUM_27456cap?
Given that these capabilities are LOCAL_CPU scope, and the systems in question never have heterogeneous CPUs, you could replace
cpus_have_const_cap() => this_cpu_has_cap()
in unmap_kernel_at_el0().
If they were heterogeneous, we would fail anyway, no matter what the order was.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 28 lines · Suzuki K Poulose
Quoted 18 lines · Mark Brown
Quoted 16 lines · dann frazier
Quoted 5 lines · Mark Brown
This will result in a renumbering and reordering of the existing constants, since they are all internal only the values should not be important. The reordering will impact the order in which some steps in enumeration handle features but the algorithm is not intended to depend on this and I haven't seen any issues when testing.
Unfortunately I believe I've hit a regression[*] due to such an ordering dependency.
UNMAP_KERNEL_AT_EL0currently needs to be processed afterWORKAROUND_CAVIUM_27456. ThunderX systems are incompatible with KPTI, sounmap_kernel_at_el0()bails ifWORKAROUND_CAVIUM_27456is set. Because of the sorting,WORKAROUND_CAVIUM_27456will not yet have been considered whenunmap_kernel_at_el0()checks for it, so the kernel tries to run w/ KPTI - and quickly falls over.Quoted 5 lines
Quoted 5 lines
I've verified that reordering cpucaps to move
WORKAROUND_CAVIUM_27456just aboveUNMAP_KERNEL_AT_EL0restores the old behavior. I'm not sure of the right way to address this - perhapsunmap_kernel_at_el0()could check cavium_erratum_27456_cpus[] directly instead of keying on theARM64_WORKAROUND_CAVIUM_27456cap?Given that these capabilities are
LOCAL_CPUscope, and the systems in question never have heterogeneous CPUs, you could replace
Quoted 6 lines
cpus_have_const_cap()=>this_cpu_has_cap()in
unmap_kernel_at_el0().If they were heterogeneous, we would fail anyway, no matter what the order was.
That seems to me to be the simplest approach, and I've verified it addresses the problem. I'll prepare a patch. Thanks Suzuki.
-dann
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel