Will Deacon [Tue, 6 Dec 2022 11:33:29 +0000 (11:33 +0000)]
Merge branch 'for-next/trivial' into for-next/core
* for-next/trivial:
arm64: alternatives: add __init/__initconst to some functions/variables
arm64/asm: Remove unused assembler DAIF save/restore macros
arm64/kpti: Move DAIF masking to C code
Revert "arm64/mm: Drop redundant BUG_ON(!pgtable_alloc)"
arm64/mm: Drop unused restore_ttbr1
arm64: alternatives: make apply_alternatives_vdso() static
arm64/mm: Drop idmap_pg_end[] declaration
arm64/mm: Drop redundant BUG_ON(!pgtable_alloc)
arm64: make is_ttbrX_addr() noinstr-safe
arm64/signal: Document our convention for choosing magic numbers
arm64: atomics: lse: remove stale dependency on JUMP_LABEL
arm64: paravirt: remove conduit check in has_pv_steal_clock
arm64: entry: Fix typo
arm64/booting: Add missing colon to FA64 entry
arm64/mm: Drop ARM64_KERNEL_USES_PMD_MAPS
arm64/asm: Remove unused enable_da macro
Will Deacon [Tue, 6 Dec 2022 11:32:25 +0000 (11:32 +0000)]
Merge branch 'for-next/sysregs' into for-next/core
* for-next/sysregs: (39 commits)
arm64/sysreg: Remove duplicate definitions from asm/sysreg.h
arm64/sysreg: Convert ID_DFR1_EL1 to automatic generation
arm64/sysreg: Convert ID_DFR0_EL1 to automatic generation
arm64/sysreg: Convert ID_AFR0_EL1 to automatic generation
arm64/sysreg: Convert ID_MMFR5_EL1 to automatic generation
arm64/sysreg: Convert MVFR2_EL1 to automatic generation
arm64/sysreg: Convert MVFR1_EL1 to automatic generation
arm64/sysreg: Convert MVFR0_EL1 to automatic generation
arm64/sysreg: Convert ID_PFR2_EL1 to automatic generation
arm64/sysreg: Convert ID_PFR1_EL1 to automatic generation
arm64/sysreg: Convert ID_PFR0_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR6_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR5_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR4_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR3_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR2_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR1_EL1 to automatic generation
arm64/sysreg: Convert ID_ISAR0_EL1 to automatic generation
arm64/sysreg: Convert ID_MMFR4_EL1 to automatic generation
arm64/sysreg: Convert ID_MMFR3_EL1 to automatic generation
...
Will Deacon [Tue, 6 Dec 2022 11:27:28 +0000 (11:27 +0000)]
Merge branch 'for-next/sve-state' into for-next/core
* for-next/sve-state:
arm64/fp: Use a struct to pass data to fpsimd_bind_state_to_cpu()
arm64/sve: Leave SVE enabled on syscall if we don't context switch
arm64/fpsimd: SME no longer requires SVE register state
arm64/fpsimd: Load FP state based on recorded data type
arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM
arm64/fpsimd: Have KVM explicitly say which FP registers to save
arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE
KVM: arm64: Discard any SVE state when entering KVM guests
Will Deacon [Tue, 6 Dec 2022 11:26:40 +0000 (11:26 +0000)]
Merge branch 'for-next/stacks' into for-next/core
* for-next/stacks:
arm64: move on_thread_stack() to <asm/stacktrace.h>
arm64: remove current_top_of_stack()
Will Deacon [Tue, 6 Dec 2022 11:25:43 +0000 (11:25 +0000)]
Merge branch 'for-next/selftests' into for-next/core
* for-next/selftests:
kselftest/arm64: Allow epoll_wait() to return more than one result
kselftest/arm64: Don't drain output while spawning children
kselftest/arm64: Hold fp-stress children until they're all spawned
kselftest/arm64: Set test names prior to starting children
kselftest/arm64: Use preferred form for predicate load/stores
kselftest/arm64: fix array_size.cocci warning
kselftest/arm64: fix array_size.cocci warning
kselftest/arm64: Print ASCII version of unknown signal frame magic values
kselftest/arm64: Remove validation of extra_context from TODO
kselftest/arm64: Provide progress messages when signalling children
kselftest/arm64: Check that all children are producing output in fp-stress
Will Deacon [Tue, 6 Dec 2022 11:22:48 +0000 (11:22 +0000)]
Merge branch 'for-next/perf' into for-next/core
* for-next/perf: (21 commits)
arm_pmu: Drop redundant armpmu->map_event() in armpmu_event_init()
drivers/perf: hisi: Add TLP filter support
Documentation: perf: Indent filter options list of hisi-pcie-pmu
docs: perf: Fix PMU instance name of hisi-pcie-pmu
drivers/perf: hisi: Fix some event id for hisi-pcie-pmu
arm64/perf: Replace PMU version number '0' with ID_AA64DFR0_EL1_PMUVer_NI
perf/amlogic: Remove unused header inclusions of <linux/version.h>
perf/amlogic: Fix build error for x86_64 allmodconfig
dt-binding: perf: Add Amlogic DDR PMU
docs/perf: Add documentation for the Amlogic G12 DDR PMU
perf/amlogic: Add support for Amlogic meson G12 SoC DDR PMU driver
MAINTAINERS: Update HiSilicon PMU maintainers
perf: arm_cspmu: Fix module cyclic dependency
perf: arm_cspmu: Fix build failure on x86_64
perf: arm_cspmu: Fix modular builds due to missing MODULE_LICENSE()s
perf: arm_cspmu: Add support for NVIDIA SCF and MCF attribute
perf: arm_cspmu: Add support for ARM CoreSight PMU driver
perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()
perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()
drivers: perf: marvell_cn10k: Fix hotplug callback leak in tad_pmu_init()
...
Will Deacon [Tue, 6 Dec 2022 11:21:21 +0000 (11:21 +0000)]
Merge branch 'for-next/mm' into for-next/core
* for-next/mm:
arm64: booting: Require placement within 48-bit addressable memory
arm64: mm: kfence: only handle translation faults
arm64/mm: Simplify and document pte_to_phys() for 52 bit addresses
Will Deacon [Tue, 6 Dec 2022 11:20:21 +0000 (11:20 +0000)]
Merge branch 'for-next/kprobes' into for-next/core
* for-next/kprobes:
arm64: kprobes: Return DBG_HOOK_ERROR if kprobes can not handle a BRK
arm64: kprobes: Let arch do_page_fault() fix up page fault in user handler
arm64: Prohibit instrumentation on arch_stack_walk()
Will Deacon [Tue, 6 Dec 2022 11:16:20 +0000 (11:16 +0000)]
Merge branch 'for-next/kdump' into for-next/core
* for-next/kdump:
arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones
arm64: kdump: Provide default size when crashkernel=Y,low is not specified
Will Deacon [Tue, 6 Dec 2022 11:15:50 +0000 (11:15 +0000)]
Merge branch 'for-next/kbuild' into for-next/core
* for-next/kbuild:
arm64: remove special treatment for the link order of head.o
Will Deacon [Tue, 6 Dec 2022 11:14:25 +0000 (11:14 +0000)]
Merge branch 'for-next/insn' into for-next/core
* for-next/insn:
arm64:uprobe fix the uprobe SWBP_INSN in big-endian
arm64: insn: always inline hint generation
arm64: insn: simplify insn group identification
arm64: insn: always inline predicates
arm64: insn: remove aarch64_insn_gen_prefetch()
Will Deacon [Tue, 6 Dec 2022 11:07:39 +0000 (11:07 +0000)]
Merge branch 'for-next/ftrace' into for-next/core
* for-next/ftrace:
ftrace: arm64: remove static ftrace
ftrace: arm64: move from REGS to ARGS
ftrace: abstract DYNAMIC_FTRACE_WITH_ARGS accesses
ftrace: rename ftrace_instruction_pointer_set() -> ftrace_regs_set_instruction_pointer()
ftrace: pass fregs to arch_ftrace_set_direct_caller()
Will Deacon [Tue, 6 Dec 2022 11:06:47 +0000 (11:06 +0000)]
Merge branch 'for-next/fpsimd' into for-next/core
* for-next/fpsimd:
arm64/fpsimd: Make kernel_neon_ API _GPL
Will Deacon [Tue, 6 Dec 2022 11:06:04 +0000 (11:06 +0000)]
Merge branch 'for-next/ffa' into for-next/core
* for-next/ffa:
firmware: arm_ffa: Move comment before the field it is documenting
firmware: arm_ffa: Move constants to header file
Will Deacon [Tue, 6 Dec 2022 11:04:47 +0000 (11:04 +0000)]
Merge branch 'for-next/errata' into for-next/core
* for-next/errata:
arm64: errata: Workaround possible Cortex-A715 [ESR|FAR]_ELx corruption
arm64: Add Cortex-715 CPU part definition
Will Deacon [Tue, 6 Dec 2022 11:01:49 +0000 (11:01 +0000)]
Merge branch 'for-next/dynamic-scs' into for-next/core
* for-next/dynamic-scs:
arm64: implement dynamic shadow call stack for Clang
scs: add support for dynamic shadow call stacks
arm64: unwind: add asynchronous unwind tables to kernel and modules
Will Deacon [Tue, 6 Dec 2022 10:44:07 +0000 (10:44 +0000)]
Merge branch 'for-next/cpufeature' into for-next/core
* for-next/cpufeature:
kselftest/arm64: Add SVE 2.1 to hwcap test
arm64/hwcap: Add support for SVE 2.1
kselftest/arm64: Add FEAT_RPRFM to the hwcap test
arm64/hwcap: Add support for FEAT_RPRFM
kselftest/arm64: Add FEAT_CSSC to the hwcap selftest
arm64/hwcap: Add support for FEAT_CSSC
arm64: Enable data independent timing (DIT) in the kernel
Will Deacon [Tue, 6 Dec 2022 10:42:33 +0000 (10:42 +0000)]
Merge branch 'for-next/asm-const' into for-next/core
* for-next/asm-const:
arm64: alternative: constify alternative_has_feature_* argument
arm64: jump_label: mark arguments as const to satisfy asm constraints
Will Deacon [Tue, 6 Dec 2022 10:36:52 +0000 (10:36 +0000)]
Merge branch 'for-next/acpi' into for-next/core
* for-next/acpi:
ACPI: APMT: Fix kerneldoc and indentation
ACPI: Enable FPDT on arm64
arm_pmu: acpi: handle allocation failure
arm_pmu: rework ACPI probing
arm_pmu: factor out PMU matching
arm_pmu: acpi: factor out PMU<->CPU association
ACPI/IORT: Update SMMUv3 DeviceID support
ACPI: ARM Performance Monitoring Unit Table (APMT) initial support
Masami Hiramatsu (Google) [Fri, 2 Dec 2022 02:18:52 +0000 (11:18 +0900)]
arm64: kprobes: Return DBG_HOOK_ERROR if kprobes can not handle a BRK
Return DBG_HOOK_ERROR if kprobes can not handle a BRK because it
fails to find a kprobe corresponding to the address.
Since arm64 kprobes uses stop_machine based text patching for removing
BRK, it ensures all running kprobe_break_handler() is done at that point.
And after removing the BRK, it removes the kprobe from its hash list.
Thus, if the kprobe_break_handler() fails to find kprobe from hash list,
there is a bug.
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/166994753273.439920.6629626290560350760.stgit@devnote3
Signed-off-by: Will Deacon <will@kernel.org>
Masami Hiramatsu (Google) [Fri, 2 Dec 2022 02:18:42 +0000 (11:18 +0900)]
arm64: kprobes: Let arch do_page_fault() fix up page fault in user handler
Since arm64's do_page_fault() can handle the page fault correctly
than kprobe_fault_handler() according to the context, let it handle
the page fault instead of simply call fixup_exception() in the
kprobe_fault_handler().
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/166994752269.439920.4801339965959400456.stgit@devnote3
Signed-off-by: Will Deacon <will@kernel.org>
Masami Hiramatsu (Google) [Fri, 2 Dec 2022 02:18:33 +0000 (11:18 +0900)]
arm64: Prohibit instrumentation on arch_stack_walk()
Mark arch_stack_walk() as noinstr instead of notrace and inline functions
called from arch_stack_walk() as __always_inline so that user does not
put any instrumentations on it, because this function can be used from
return_address() which is used by lockdep.
Without this, if the kernel built with CONFIG_LOCKDEP=y, just probing
arch_stack_walk() via <tracefs>/kprobe_events will crash the kernel on
arm64.
# echo p arch_stack_walk >> ${TRACEFS}/kprobe_events
# echo 1 > ${TRACEFS}/events/kprobes/enable
kprobes: Failed to recover from reentered kprobes.
kprobes: Dump kprobe:
.symbol_name = arch_stack_walk, .offset = 0, .addr = arch_stack_walk+0x0/0x1c0
------------[ cut here ]------------
kernel BUG at arch/arm64/kernel/probes/kprobes.c:241!
kprobes: Failed to recover from reentered kprobes.
kprobes: Dump kprobe:
.symbol_name = arch_stack_walk, .offset = 0, .addr = arch_stack_walk+0x0/0x1c0
------------[ cut here ]------------
kernel BUG at arch/arm64/kernel/probes/kprobes.c:241!
PREEMPT SMP
Modules linked in:
CPU: 0 PID: 17 Comm: migration/0 Tainted: G N 6.1.0-rc5+ #6
Hardware name: linux,dummy-virt (DT)
Stopper: 0x0 <- 0x0
pstate:
600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kprobe_breakpoint_handler+0x178/0x17c
lr : kprobe_breakpoint_handler+0x178/0x17c
sp :
ffff8000080d3090
x29:
ffff8000080d3090 x28:
ffff0df5845798c0 x27:
ffffc4f59057a774
x26:
ffff0df5ffbba770 x25:
ffff0df58f420f18 x24:
ffff49006f641000
x23:
ffffc4f590579768 x22:
ffff0df58f420f18 x21:
ffff8000080d31c0
x20:
ffffc4f590579768 x19:
ffffc4f590579770 x18:
0000000000000006
x17:
5f6b636174735f68 x16:
637261203d207264 x15:
64612e202c30203d
x14:
2074657366666f2e x13:
30633178302f3078 x12:
302b6b6c61775f6b
x11:
636174735f686372 x10:
ffffc4f590dc5bd8 x9 :
ffffc4f58eb31958
x8 :
00000000ffffefff x7 :
ffffc4f590dc5bd8 x6 :
80000000fffff000
x5 :
000000000000bff4 x4 :
0000000000000000 x3 :
0000000000000000
x2 :
0000000000000000 x1 :
ffff0df5845798c0 x0 :
0000000000000064
Call trace:
kprobes: Failed to recover from reentered kprobes.
kprobes: Dump kprobe:
.symbol_name = arch_stack_walk, .offset = 0, .addr = arch_stack_walk+0x0/0x1c0
------------[ cut here ]------------
kernel BUG at arch/arm64/kernel/probes/kprobes.c:241!
Fixes:
39ef362d2d45 ("arm64: Make return_address() use arch_stack_walk()")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/166994751368.439920.3236636557520824664.stgit@devnote3
Signed-off-by: Will Deacon <will@kernel.org>
junhua huang [Fri, 2 Dec 2022 07:11:10 +0000 (15:11 +0800)]
arm64:uprobe fix the uprobe SWBP_INSN in big-endian
We use uprobe in aarch64_be, which we found the tracee task would exit
due to SIGILL when we enable the uprobe trace.
We can see the replace inst from uprobe is not correct in aarch big-endian.
As in Armv8-A, instruction fetches are always treated as little-endian,
we should treat the UPROBE_SWBP_INSN as little-endian。
The test case is as following。
bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
bash-4.4# cd /sys/kernel/debug/tracing/
bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
bash-4.4# echo 1 > events/uprobes/enable
bash-4.4#
bash-4.4# ps
PID TTY TIME CMD
140 ? 00:00:01 bash
237 ? 00:00:00 ps
[1]+ Illegal instruction ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null
which we debug use gdb as following:
bash-4.4# gdb attach 155
(gdb) disassemble send
Dump of assembler code for function send:
0x0000000000400c30 <+0>: .inst 0xa00020d4 ; undefined
0x0000000000400c34 <+4>: mov x29, sp
0x0000000000400c38 <+8>: str w0, [sp, #28]
0x0000000000400c3c <+12>: strb w1, [sp, #27]
0x0000000000400c40 <+16>: str xzr, [sp, #40]
0x0000000000400c44 <+20>: str xzr, [sp, #48]
0x0000000000400c48 <+24>: add x0, sp, #0x1b
0x0000000000400c4c <+28>: mov w3, #0x0 // #0
0x0000000000400c50 <+32>: mov x2, #0x1 // #1
0x0000000000400c54 <+36>: mov x1, x0
0x0000000000400c58 <+40>: ldr w0, [sp, #28]
0x0000000000400c5c <+44>: bl 0x405e10 <mq_send>
0x0000000000400c60 <+48>: str w0, [sp, #60]
0x0000000000400c64 <+52>: ldr w0, [sp, #60]
0x0000000000400c68 <+56>: ldp x29, x30, [sp], #64
0x0000000000400c6c <+60>: ret
End of assembler dump.
(gdb) info b
No breakpoints or watchpoints.
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
0x0000000000400c30 in send ()
(gdb) x/10x 0x400c30
0x400c30 <send>: 0xd42000a0 0xfd030091 0xe01f00b9 0xe16f0039
0x400c40 <send+16>: 0xff1700f9 0xff1b00f9 0xe06f0091 0x03008052
0x400c50 <send+32>: 0x220080d2 0xe10300aa
(gdb) disassemble 0x400c30
Dump of assembler code for function send:
=> 0x0000000000400c30 <+0>: .inst 0xa00020d4 ; undefined
0x0000000000400c34 <+4>: mov x29, sp
0x0000000000400c38 <+8>: str w0, [sp, #28]
0x0000000000400c3c <+12>: strb w1, [sp, #27]
0x0000000000400c40 <+16>: str xzr, [sp, #40]
Signed-off-by: junhua huang <huang.junhua@zte.com.cn>
Link: https://lore.kernel.org/r/202212021511106844809@zte.com.cn
Signed-off-by: Will Deacon <will@kernel.org>
Jisheng Zhang [Fri, 2 Dec 2022 16:18:59 +0000 (00:18 +0800)]
arm64: alternatives: add __init/__initconst to some functions/variables
apply_alternatives_vdso(), __apply_alternatives_multi_stop() and
kernel_alternatives are not needed after booting, so mark the two
functions as __init and the var as __initconst.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://lore.kernel.org/r/20221202161859.2228-1-jszhang@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Anshuman Khandual [Fri, 2 Dec 2022 01:56:11 +0000 (07:26 +0530)]
arm_pmu: Drop redundant armpmu->map_event() in armpmu_event_init()
__hw_perf_event_init() already calls armpmu->map_event() callback, and also
returns its error code including -ENOENT, along with a debug callout. Hence
an additional armpmu->map_event() check for -ENOENT is redundant.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20221202015611.338499-1-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 29 Nov 2022 21:59:25 +0000 (21:59 +0000)]
kselftest/arm64: Allow epoll_wait() to return more than one result
When everything is starting up we are likely to have a lot of child
processes producing output at once. This means that we can reduce
overhead a bit by allowing epoll_wait() to return more than one
descriptor at once, it cuts down on the number of system calls we need
to do which on virtual platforms where the syscall overhead is a bit
more noticable and we're likely to have a lot more children active can
make a small but noticable difference.
On physical platforms the relatively small number of processes being run
and vastly improved speeds push the effects of this change into the
noise.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221129215926.442895-4-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 29 Nov 2022 21:59:24 +0000 (21:59 +0000)]
kselftest/arm64: Don't drain output while spawning children
Now we hold execution of the stress test programs until all children are
started there is no need to drain output while that is happening.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221129215926.442895-3-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 29 Nov 2022 21:59:23 +0000 (21:59 +0000)]
kselftest/arm64: Hold fp-stress children until they're all spawned
At present fp-stress has a bit of a thundering herd problem since the
children it spawns start running immediately, meaning that they can start
starving the parent process of CPU before it has even started all the
children. This is much more severe on virtual platforms since they tend to
support far more SVE and SME vector lengths, be slower in general and for
some have issues with performance when simulating multiple CPUs.
We can mitigate this problem by having all the child processes block before
starting the test program, meaning that we at least have all the child
processes started before we start heavily using CPU. We still have the same
load issues while waiting for the actual stress test programs to start up
and produce output but they're at least all ready to go before that kicks
in, resulting in substantial reductions in overall runtime on some of the
severely affected systems. One test was showing about 20% improvement.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221129215926.442895-2-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Will Deacon [Thu, 1 Dec 2022 17:31:12 +0000 (17:31 +0000)]
arm64/sysreg: Remove duplicate definitions from asm/sysreg.h
With the new-fangled generation of asm/sysreg-defs.h, some definitions
have ended up being duplicated between the two files.
Remove these duplicate definitions, and consolidate the naming for
GMID_EL1_BS_WIDTH.
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:37 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_DFR1_EL1 to automatic generation
Convert ID_DFR1_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-39-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:36 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_DFR0_EL1 to automatic generation
Convert ID_DFR0_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221130171637.718182-38-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:35 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_AFR0_EL1 to automatic generation
Convert ID_AFR0_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-37-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:34 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_MMFR5_EL1 to automatic generation
Convert ID_MMFR5_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-36-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:33 +0000 (17:16 +0000)]
arm64/sysreg: Convert MVFR2_EL1 to automatic generation
Convert MVFR2_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-35-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:32 +0000 (17:16 +0000)]
arm64/sysreg: Convert MVFR1_EL1 to automatic generation
Convert MVFR1_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-34-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:31 +0000 (17:16 +0000)]
arm64/sysreg: Convert MVFR0_EL1 to automatic generation
Convert MVFR0_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-33-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:30 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_PFR2_EL1 to automatic generation
Convert ID_PFR2_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-32-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:29 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_PFR1_EL1 to automatic generation
Convert ID_PFR1_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-31-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:28 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_PFR0_EL1 to automatic generation
Convert ID_PFR0_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221130171637.718182-30-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:27 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR6_EL1 to automatic generation
Convert ID_ISAR6_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-29-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:26 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR5_EL1 to automatic generation
Convert ID_ISAR5_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-28-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:25 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR4_EL1 to automatic generation
Convert ID_ISAR4_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-27-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:24 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR3_EL1 to automatic generation
Convert ID_ISAR3_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-26-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:23 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR2_EL1 to automatic generation
Convert ID_ISAR2_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-25-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:22 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR1_EL1 to automatic generation
Convert ID_ISAR1_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-24-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:21 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_ISAR0_EL1 to automatic generation
Convert ID_ISAR0_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-23-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:20 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_MMFR4_EL1 to automatic generation
Convert ID_MMFR4_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-22-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:19 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_MMFR3_EL1 to automatic generation
Convert ID_MMFR3_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-21-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:18 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_MMFR2_EL1 to automatic generation
Convert ID_MMFR2_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-20-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:17 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_MMFR1_EL1 to automatic generation
Convert ID_MMFR1_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-19-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:16 +0000 (17:16 +0000)]
arm64/sysreg: Convert ID_MMFR0_EL1 to automatic generation
Convert ID_MMFR0_EL1 to be automatically generated as per DDI0487I.a,
no functional changes.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-18-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:15 +0000 (17:16 +0000)]
arm64/sysreg: Extend the maximum width of a register and symbol name
32bit has multiple values for its id registers, as extra properties
were added to the CPUs. Some of these end up having long names, which
exceed the fixed 48 character column that the sysreg awk script generates.
For example, the ID_MMFR1_EL1.L1Hvd field has an encoding whose natural
name would be 'invalidate Iside only'. Using this causes compile errors
as the script generates the following:
#define ID_MMFR1_EL1_L1Hvd_INVALIDATE_ISIDE_ONLYUL(0b0001)
Add a few extra characters.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-17-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:14 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for MVFR2_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the MVFR2_EL1 register use lower-case for feature
names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-16-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:13 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for MVFR1_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the MVFR1_EL1 register use lower-case for feature
names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-15-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:12 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for MVFR0_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the MVFR0_EL1 register use lower-case for feature
names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-14-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:11 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_DFR1_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_DFR1_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-13-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:10 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_DFR0_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_DFR0_EL1 register have an _EL1 suffix,
and use lower-case for feature names where the arm-arm does the same.
The arm-arm has feature names for some of the ID_DFR0_EL1.PerMon encodings.
Use these feature names in preference to the '8_4' indication of the
architecture version they were introduced in.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-12-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:09 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_PFR2_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_PFR2_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-11-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:08 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_PFR1_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_PFR1_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-10-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:07 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_PFR0_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_PFR0_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-9-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:06 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_ISAR6_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR6_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-8-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:05 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_ISAR5_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR5_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-7-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:04 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_ISAR4_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR4_EL1 register have an _EL1 suffix,
and use lower-case for feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-6-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:03 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_ISAR0_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR0_EL1 register have an _EL1 suffix,
and use lower-case for feature names where the arm-arm does the same.
To functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-5-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:02 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_MMFR5_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_MMFR5_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-4-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:01 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_MMFR4_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_MMFR4_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-3-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
James Morse [Wed, 30 Nov 2022 17:16:00 +0000 (17:16 +0000)]
arm64/sysreg: Standardise naming for ID_MMFR0_EL1
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates. The scripts would like to follow exactly what is in the
arm-arm, which uses lower case for some of these feature names.
Ensure symbols for the ID_MMFR0_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-2-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Will Deacon [Wed, 16 Nov 2022 17:03:25 +0000 (17:03 +0000)]
firmware: arm_ffa: Move comment before the field it is documenting
This is consistent with the other comments in the struct.
Co-developed-by: Andrew Walbran <qwandor@google.com>
Signed-off-by: Andrew Walbran <qwandor@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20221116170335.2341003-3-qperret@google.com
Signed-off-by: Will Deacon <will@kernel.org>
Will Deacon [Wed, 16 Nov 2022 17:03:24 +0000 (17:03 +0000)]
firmware: arm_ffa: Move constants to header file
FF-A function IDs and error codes will be needed in the hypervisor too,
so move to them to the header file where they can be shared. Rename the
version constants with an "FFA_" prefix so that they are less likely
to clash with other code in the tree.
Co-developed-by: Andrew Walbran <qwandor@google.com>
Signed-off-by: Andrew Walbran <qwandor@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20221116170335.2341003-2-qperret@google.com
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:40 +0000 (09:46 +0000)]
arm64/fp: Use a struct to pass data to fpsimd_bind_state_to_cpu()
For reasons that are unclear to this reader fpsimd_bind_state_to_cpu()
populates the struct fpsimd_last_state_struct that it uses to store the
active floating point state for KVM guests by passing an argument for
each member of the structure. As the richness of the architecture increases
this is resulting in a function with a rather large number of arguments
which isn't ideal.
Simplify the interface by using the struct directly as the single argument
for the function, renaming it as we lift the definition into the header.
This could be built on further to reduce the work we do adding storage for
new FP state in various places but for now it just simplifies this one
interface.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-9-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:39 +0000 (09:46 +0000)]
arm64/sve: Leave SVE enabled on syscall if we don't context switch
The syscall ABI says that the SVE register state not shared with FPSIMD
may not be preserved on syscall, and this is the only mechanism we have
in the ABI to stop tracking the extra SVE state for a process. Currently
we do this unconditionally by means of disabling SVE for the process on
syscall, causing userspace to take a trap to EL1 if it uses SVE again.
These extra traps result in a noticeable overhead for using SVE instead
of FPSIMD in some workloads, especially for simple syscalls where we can
return directly to userspace and would not otherwise need to update the
floating point registers. Tests with fp-pidbench show an approximately
70% overhead on a range of implementations when SVE is in use - while
this is an extreme and entirely artificial benchmark it is clear that
there is some useful room for improvement here.
Now that we have the ability to track the decision about what to save
seprately to TIF_SVE we can improve things by leaving TIF_SVE enabled on
syscall but only saving the FPSIMD registers if we are in a syscall.
This means that if we need to restore the register state from memory
(eg, after a context switch or kernel mode NEON) we will drop TIF_SVE
and reenable traps for userspace but if we can just return to userspace
then traps will remain disabled.
Since our current implementation and hence ABI has the effect of zeroing
all the SVE register state not shared with FPSIMD on syscall we replace
the disabling of TIF_SVE with a flush of the non-shared register state,
this means that there is still some overhead for syscalls when SVE is in
use but it is very much reduced.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-8-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:38 +0000 (09:46 +0000)]
arm64/fpsimd: SME no longer requires SVE register state
Now that we track the type of the stored register state separately to
what is active in the task, it is valid to have the FPSIMD register
state stored while in streaming mode. Remove the special case handling
for SME when setting FPSIMD register state.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-7-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:37 +0000 (09:46 +0000)]
arm64/fpsimd: Load FP state based on recorded data type
Now that we are recording the type of floating point register state we
are saving when we write the register state out to memory we can use
that information when we load from memory to decide which format to
load, bringing TIF_SVE into line with what we saved rather than relying
on TIF_SVE to determine what to load.
The SME state details are already recorded directly in the saved
SVCR and handled based on the information there.
Since we are not changing any of the save paths there should be no
functional change from this patch, further patches will make use of this
to optimise and clarify the code.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-6-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:36 +0000 (09:46 +0000)]
arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM
Now that we are explicitly telling the host FP code which register state
it needs to save we can remove the manipulation of TIF_SVE from the KVM
code, simplifying it and allowing us to optimise our handling of normal
tasks. Remove the manipulation of TIF_SVE from KVM and instead rely on
to_save to ensure we save the correct data for it.
There should be no functional or performance impact from this change.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-5-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:35 +0000 (09:46 +0000)]
arm64/fpsimd: Have KVM explicitly say which FP registers to save
In order to avoid needlessly saving and restoring the guest registers KVM
relies on the host FPSMID code to save the guest registers when we context
switch away from the guest. This is done by binding the KVM guest state to
the CPU on top of the task state that was originally there, then carefully
managing the TIF_SVE flag for the task to cause the host to save the full
SVE state when needed regardless of the needs of the host task. This works
well enough but isn't terribly direct about what is going on and makes it
much more complicated to try to optimise what we're doing with the SVE
register state.
Let's instead have KVM pass in the register state it wants saving when it
binds to the CPU. We introduce a new FP_STATE_CURRENT for use
during normal task binding to indicate that we should base our
decisions on the current task. This should not be used when
actually saving. Ideally we might want to use a separate enum for
the type to save but this enum and the enum values would then
need to be named which has problems with clarity and ambiguity.
In order to ease any future debugging that might be required this patch
does not actually update any of the decision making about what to save,
it merely starts tracking the new information and warns if the requested
state is not what we would otherwise have decided to save.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-4-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:34 +0000 (09:46 +0000)]
arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE
When we save the state for the floating point registers this can be done
in the form visible through either the FPSIMD V registers or the SVE Z and
P registers. At present we track which format is currently used based on
TIF_SVE and the SME streaming mode state but particularly in the SVE case
this limits our options for optimising things, especially around syscalls.
Introduce a new enum which we place together with saved floating point
state in both thread_struct and the KVM guest state which explicitly
states which format is active and keep it up to date when we change it.
At present we do not use this state except to verify that it has the
expected value when loading the state, future patches will introduce
functional changes.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-3-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 15 Nov 2022 09:46:33 +0000 (09:46 +0000)]
KVM: arm64: Discard any SVE state when entering KVM guests
Since
8383741ab2e773a99 (KVM: arm64: Get rid of host SVE tracking/saving)
KVM has not tracked the host SVE state, relying on the fact that we
currently disable SVE whenever we perform a syscall. This may not be true
in future since performance optimisation may result in us keeping SVE
enabled in order to avoid needing to take access traps to reenable it.
Handle this by clearing TIF_SVE and converting the stored task state to
FPSIMD format when preparing to run the guest. This is done with a new
call fpsimd_kvm_prepare() to keep the direct state manipulation
functions internal to fpsimd.c.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-2-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Yicong Yang [Thu, 17 Nov 2022 08:41:36 +0000 (16:41 +0800)]
drivers/perf: hisi: Add TLP filter support
The PMU support to filter the TLP when counting the bandwidth with below
options:
- only count the TLP headers
- only count the TLP payloads
- count both TLP headers and payloads
In the current driver it's default to count the TLP payloads only, which
will have an implicity side effects that on the traffic only have header
only TLPs, we'll get no data.
Make this user configuration through "len_mode" parameter and make it
default to count both TLP headers and payloads when user not specified.
Also update the documentation for it.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20221117084136.53572-5-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Bagas Sanjaya [Thu, 17 Nov 2022 08:41:35 +0000 (16:41 +0800)]
Documentation: perf: Indent filter options list of hisi-pcie-pmu
The "Filter options" list have a rather ugly indentation. Also, the first
paragraph after list name is rendered without separator (as continuation
from the name).
Align the list by indenting the list items and add a blank line
separator for each list name.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20221117084136.53572-4-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Yicong Yang [Thu, 17 Nov 2022 08:41:34 +0000 (16:41 +0800)]
docs: perf: Fix PMU instance name of hisi-pcie-pmu
The PMU instance will be called hisi_pcie<sicl>_core<core> rather than
hisi_pcie<sicl>_<core>. Fix this in the documentation.
Fixes:
c8602008e247 ("docs: perf: Add description for HiSilicon PCIe PMU driver")
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20221117084136.53572-3-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Yicong Yang [Thu, 17 Nov 2022 08:41:33 +0000 (16:41 +0800)]
drivers/perf: hisi: Fix some event id for hisi-pcie-pmu
Some event id of hisi-pcie-pmu is incorrect, fix them.
Fixes:
8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20221117084136.53572-2-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Anshuman Khandual [Mon, 28 Nov 2022 02:54:49 +0000 (08:24 +0530)]
arm64/perf: Replace PMU version number '0' with ID_AA64DFR0_EL1_PMUVer_NI
__armv8pmu_probe_pmu() returns if detected PMU is either not implemented or
implementation defined. Extracted ID_AA64DFR0_EL1_PMUVer value, when PMU is
not implemented is '0' which can be replaced with ID_AA64DFR0_EL1_PMUVer_NI
defined as '0b0000'.
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-perf-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20221128025449.39085-1-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Jiapeng Chong [Tue, 29 Nov 2022 03:21:08 +0000 (11:21 +0800)]
perf/amlogic: Remove unused header inclusions of <linux/version.h>
According to the "Abaci Robot":
| ./drivers/perf/amlogic/meson_g12_ddr_pmu.c:15 linux/version.h not needed.
| ./drivers/perf/amlogic/meson_ddr_pmu_core.c: 19 linux/version.h not needed.
So drop the unnecessary #include directives.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3280
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3282
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20221129032108.119661-1-jiapeng.chong@linux.alibaba.com
Link: https://lore.kernel.org/r/20221129032108.119661-2-jiapeng.chong@linux.alibaba.com
[will: Squashed patches together, filled out commit message a bit more]
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Thu, 24 Nov 2022 12:07:22 +0000 (12:07 +0000)]
kselftest/arm64: Set test names prior to starting children
Since we now flush output immediately on starting children we should ensure
that the child name is set beforehand so that any output that does get
flushed from the newly created child has the name of the child attached.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221124120722.150988-1-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Ard Biesheuvel [Tue, 22 Nov 2022 17:02:49 +0000 (18:02 +0100)]
arm64: booting: Require placement within 48-bit addressable memory
Some configurations (i.e., 64k + LVA/LPA) can tolerate a physical
placement of the kernel image outside of the 48-bit addressable region,
but given that the loader has no way of knowing whether or not the image
in question supports LVA/LPA, it currently has no choice but to place it
below the 48-bit mark.
Once we add support for LPA2, which allows 52-bit physical and virtual
addressing when using 4k or 16k pages, but in way that relies on
increasing the number of paging levels, there will be more variety in
the configurations that may or may not support this.
So redefine bit #3 in the Image header as 'must be placed within 48-bit
addressable memory', as this is the current de facto meaning.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20221122170249.2453853-1-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Wed, 23 Nov 2022 18:02:09 +0000 (18:02 +0000)]
arm64/asm: Remove unused assembler DAIF save/restore macros
There are no longer any users of the assembler macros for saving and
restoring DAIF so remove them to prevent further users being added, there
are C equivalents available.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221123180209.634650-3-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Wed, 23 Nov 2022 18:02:08 +0000 (18:02 +0000)]
arm64/kpti: Move DAIF masking to C code
We really don't want to take an exception while replacing TTBR1 so we mask
DAIF during the actual update. Currently this is done in the assembly
function idmap_cpu_replace_ttbr1() but it could equally be done in the only
caller of that function, cpu_replace_ttbr1(). This simplifies the assembly
code slightly and means that when working with the code around masking DAIF
flags there is one less piece of assembly code which needs to be considered.
While we're at it add a comment which makes explicit why we are masking
DAIF in this code.
There should be no functional effect.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221123180209.634650-2-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Mark Rutland [Tue, 22 Nov 2022 16:36:24 +0000 (16:36 +0000)]
ftrace: arm64: remove static ftrace
The build test robot pointer out that there's a build failure when:
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS=y
CONFIG_DYNAMIC_FTRACE_WITH_ARGS=n
... due to some mismatched ifdeffery, some of which checks
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS, and some of which checks
CONFIG_DYNAMIC_FTRACE_WITH_ARGS, leading to some missing definitions expected
by the core code when CONFIG_DYNAMIC_FTRACE=n and consequently
CONFIG_DYNAMIC_FTRACE_WITH_ARGS=n.
There's really not much point in supporting CONFIG_DYNAMIC_FTRACE=n (AKA
static ftrace). All supported toolchains allow us to implement
DYNAMIC_FTRACE, distributions all prefer DYNAMIC_FTRACE, and both
powerpc and s390 removed support for static ftrace in commits:
0c0c52306f4792a4 ("powerpc: Only support DYNAMIC_FTRACE not static")
5d6a0163494c78ad ("s390/ftrace: enforce DYNAMIC_FTRACE if FUNCTION_TRACER is selected")
... and according to Steven, static ftrace is only supported on x86 to
allow testing that the core code still functions in this configuration.
Given that, let's simplify matters by removing arm64's support for
static ftrace. This avoids the problem originally reported, and leaves
us with less code to maintain.
Fixes:
26299b3f6ba2 ("ftrace: arm64: move from REGS to ARGS")
Link: https://lore.kernel.org/r/202211212249.livTPi3Y-lkp@intel.com
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Link: https://lore.kernel.org/r/20221122163624.1225912-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Jiucheng Xu [Tue, 22 Nov 2022 08:40:28 +0000 (16:40 +0800)]
perf/amlogic: Fix build error for x86_64 allmodconfig
The driver misses including <linux/io.h>, which causes a compilation
error with x86_64 'allmodconfig':
drivers/perf/amlogic/meson_g12_ddr_pmu.c: In function 'dmc_g12_get_freq_quick':
drivers/perf/amlogic/meson_g12_ddr_pmu.c:135:15: error: implicit declaration of function 'readl' [-Werror=implicit-function-declaration]
135 | val = readl(info->pll_reg);
| ^~~~~
drivers/perf/amlogic/meson_g12_ddr_pmu.c: In function 'dmc_g12_counter_enable':
drivers/perf/amlogic/meson_g12_ddr_pmu.c:204:9: error: implicit declaration of function 'writel' [-Werror=implicit-function-declaration]
204 | writel(clock_count, info->ddr_reg[0] + DMC_MON_G12_TIMER);
| ^~~~~~
Add the missing header to fix the build.
Fixes:
2016e2113d35 ("perf/amlogic: Add support for Amlogic meson G12 SoC DDR PMU driver")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jiucheng Xu <jiucheng.xu@amlogic.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20221122084028.572494-1-jiucheng.xu@amlogic.com
Signed-off-by: Will Deacon <will@kernel.org>
Jiucheng Xu [Mon, 21 Nov 2022 02:16:00 +0000 (10:16 +0800)]
dt-binding: perf: Add Amlogic DDR PMU
Add binding documentation for the Amlogic G12 series DDR
performance monitor unit.
Signed-off-by: Jiucheng Xu <jiucheng.xu@amlogic.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221121021602.3306998-3-jiucheng.xu@amlogic.com
Signed-off-by: Will Deacon <will@kernel.org>
Jiucheng Xu [Mon, 21 Nov 2022 02:15:59 +0000 (10:15 +0800)]
docs/perf: Add documentation for the Amlogic G12 DDR PMU
Add a user guide to show how to use DDR PMU to
monitor DDR bandwidth on Amlogic G12 SoC
Signed-off-by: Jiucheng Xu <jiucheng.xu@amlogic.com>
Reviewed-by: Chris Healy <healych@amazon.com>
Link: https://lore.kernel.org/r/20221121021602.3306998-2-jiucheng.xu@amlogic.com
Signed-off-by: Will Deacon <will@kernel.org>
Jiucheng Xu [Mon, 21 Nov 2022 02:15:58 +0000 (10:15 +0800)]
perf/amlogic: Add support for Amlogic meson G12 SoC DDR PMU driver
Add support for Amlogic Meson G12 Series SOC - DDR bandwidth PMU driver
framework and interfaces. The PMU can not only monitor the total DDR
bandwidth, but also individual IP module bandwidth.
Signed-off-by: Jiucheng Xu <jiucheng.xu@amlogic.com>
Tested-by: Chris Healy <healych@amazon.com>
Link: https://lore.kernel.org/r/20221121021602.3306998-1-jiucheng.xu@amlogic.com
Signed-off-by: Will Deacon <will@kernel.org>
Shaokun Zhang [Fri, 18 Nov 2022 06:54:00 +0000 (14:54 +0800)]
MAINTAINERS: Update HiSilicon PMU maintainers
Now Qi Liu has left HiSilicon and will no longer access to the
necessary hardware and document, remove the mail and thanks for
her's work.
While add the new maintainer Jonathan Cameron, He is skilled with
kernel and enough knowledge of the driver.
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Qi Liu <liuqi6124@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Qi Liu <liuqi6124@gmail.com>
Link: https://lore.kernel.org/r/20221118065400.48836-1-zhangshaokun@hisilicon.com
Signed-off-by: Will Deacon <will@kernel.org>
Will Deacon [Mon, 21 Nov 2022 12:52:07 +0000 (12:52 +0000)]
Revert "arm64/mm: Drop redundant BUG_ON(!pgtable_alloc)"
This reverts commit
9ed2b4616d4e846ece2a04cb5007ce1d1bd9e3f3.
Nathan reports early boot failures bisected to this change which look
related to the kPTI nG repainting. In any case, consolidating the
BUG_ON()s to a single location needs more thought, so revert the change
until this is figured out properly.
Link: https://lore.kernel.org/r/Y3pS5fdZ3MdLZ00t@dev-arch.thelio-3990X
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Anshuman Khandual [Wed, 16 Nov 2022 14:09:15 +0000 (19:39 +0530)]
arm64: errata: Workaround possible Cortex-A715 [ESR|FAR]_ELx corruption
If a Cortex-A715 cpu sees a page mapping permissions change from executable
to non-executable, it may corrupt the ESR_ELx and FAR_ELx registers, on the
next instruction abort caused by permission fault.
Only user-space does executable to non-executable permission transition via
mprotect() system call which calls ptep_modify_prot_start() and ptep_modify
_prot_commit() helpers, while changing the page mapping. The platform code
can override these helpers via __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION.
Work around the problem via doing a break-before-make TLB invalidation, for
all executable user space mappings, that go through mprotect() system call.
This overrides ptep_modify_prot_start() and ptep_modify_prot_commit(), via
defining HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION on the platform thus giving
an opportunity to intercept user space exec mappings, and do the necessary
TLB invalidation. Similar interceptions are also implemented for HugeTLB.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20221116140915.356601-3-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Anshuman Khandual [Wed, 16 Nov 2022 14:09:14 +0000 (19:39 +0530)]
arm64: Add Cortex-715 CPU part definition
Add the CPU Partnumbers for the new Arm designs.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20221116140915.356601-2-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Anshuman Khandual [Thu, 17 Nov 2022 12:31:44 +0000 (18:01 +0530)]
arm64/mm: Drop unused restore_ttbr1
restore_ttbr1 procedure is not used anywhere, hence just drop it.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20221117123144.403582-1-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Mark Rutland [Thu, 17 Nov 2022 12:09:02 +0000 (12:09 +0000)]
arm64: move on_thread_stack() to <asm/stacktrace.h>
Currently on_thread_stack() is defined in <asm/processor.h>, depending
upon definitiong from <asm/stacktrace.h> despite this header not being
included. This ends up being fragile, and any user of on_thread_stack()
must include both <asm/processor.h> and <asm/stacktrace.h>.
We organised things this way due to header dependencies back in commit:
0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin")
... but now that we no longer use current_top_of_stack(), and given that
stackleak includes <asm/stacktrace.h> via <linux/stackleak.h>, we no
longer need the definition to live in <asm/processor.h>.
Move on_thread_stack() to <asm/stacktrace.h>, where all its dependencies
are guaranteed to be defined. This requires having arm64's irq.c
explicitly include <asm/stacktrace.h>, and I've taken the opportunity to
sort the includes, which were slightly out of order.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221117120902.3974163-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Mark Rutland [Thu, 17 Nov 2022 12:09:01 +0000 (12:09 +0000)]
arm64: remove current_top_of_stack()
We no longer use current_top_of_stack() on arm64, so it can be removed.
We introduced current_top_of_stack() for STACKLEAK in commit:
0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin")
... then we figured out the intended semantics were unclear, and
reworked it in commit:
e85094c31ddb794a ("arm64: stackleak: fix current_top_of_stack()")
... then we removed the only user in commit:
0cfa2ccd285d98ad ("stackleak: rework stack high bound handling")
Given that it's no longer used, and it's very easy to misuse, this patch
removes current_top_of_stack(). For the moment, on_thread_stack() is
left where it is as moving it will change some header dependencies.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221117120902.3974163-2-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Thu, 17 Nov 2022 11:41:30 +0000 (11:41 +0000)]
kselftest/arm64: Use preferred form for predicate load/stores
The preferred form of the str/ldr for predicate registers with an immediate
of zero is to omit the zero, and the clang built in assembler rejects the
zero immediate. Drop the immediate.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221117114130.687261-1-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
projects / platform / kernel / linux-starfive.git / log