kernel/linux.git/arch/powerpc/include/asm/smp.h, branch linux-7.0.y

powerpc: Replace ASSEMBLY with ASSEMBLER in non-uapi headers

2025-09-01T07:53:29+00:00

While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembler code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This is bad since macros starting with two underscores are names that are reserved by the C language. It can also be very confusing for the developers when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize now on the __ASSEMBLER__ macro that is provided by the compilers. This is almost a completely mechanical patch (done with a simple "sed -i" statement), apart from tweaking two comments manually in arch/powerpc/include/asm/bug.h and arch/powerpc/include/asm/kasan.h (which did not have proper underscores at the end) and fixing a checkpatch error about spaces in arch/powerpc/include/asm/spu_csa.h. Signed-off-by: Thomas Huth Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250801082007.32904-3-thuth@redhat.com

powerpc/smp: Remap boot CPU onto core 0 if >= nr_cpu_ids

2024-02-14T13:14:05+00:00

If nr_cpu_ids is too low to include the boot CPU, remap the boot CPU onto logical core 0. This is achieved in two stages. In early_init_dt_scan_cpus() the boot CPU is renumbered to be on logical core 0, and the original boot core's hardware ID is recorded. Later in smp_setup_cpu_maps(), if the original boot core ID is set, the logical CPU numbers on the 0th core are skipped in the normal device tree search over CPU device tree nodes. Then the search is continued until the device tree node matching the boot core is found, and those CPUs are assigned the CPU numbers starting at 0. This allows kdump kernels to be booted with low values for nr_cpu_ids to conserve memory, while also allowing the crashing/boot CPU to be any CPU. Signed-off-by: Michael Ellerman Tested-by: Wen Xiong Link: https://msgid.link/20231229120107.2281153-5-mpe@ellerman.id.au

powerpc/cpu: Mark start_secondary_resume() __noreturn

2023-03-08T16:44:24+00:00

start_secondary_resume() doesn't return. Annotate it as such. By extension this also makes arch_cpu_idle_dead() noreturn. Acked-by: Michael Ellerman (powerpc) Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/r/b6b2141f832d8cd8ade65f190d04b011cda5f9bb.1676358308.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

powerpc/64: Move paca allocation to early_setup()

2023-02-10T11:19:56+00:00

The early paca and boot cpuid dance is complicated and currently does not quite work as expected for boot cpuid != 0 cases. early_init_devtree() currently allocates the paca_ptrs and boot cpuid paca, but until that returns and early_setup() calls setup_paca(), this thread is currently still executing with smp_processor_id() == 0. One problem this causes is the paca_ptrs[smp_processor_id()] pointer is poisoned, so valid_emergency_stack() (any backtrace) and any similar users will crash. Another is that the hardware id which is set here will not be returned by get_hard_smp_processor_id(smp_processor_id()), but it would work correctly for boot_cpuid == 0, which could lead to difficult to reproduce or find bugs. The hard id does not seem to be used by the rest of early_init_devtree(), it just looks like all this code might have been put here to allocate somewhere to store boot CPU hardware id while scanning the devtree. Rearrange things so the hwid is put in a global variable like boot_cpuid, and do all the paca allocation and boot paca setup in the 64-bit early_setup() after we have everything ready to go. The paca_ptrs[0] re-poisoning code in early_setup does not seem to have ever worked, because paca_ptrs[0] was never not-poisoned when boot_cpuid is not 0. Signed-off-by: Nicholas Piggin [mpe: Fix build error on 32-bit] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221216115930.2667772-4-npiggin@gmail.com

powerpc/smp: Remove unused inline functions

2022-05-04T09:37:46+00:00

commit 441c19c8a290 ("powerpc/kvm/book3s_hv: Rework the secondary inhibit code") left behind this, so can remove it. Signed-off-by: YueHaibing Reviewed-by: Daniel Axtens Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210324140752.11320-1-yuehaibing@huawei.com

powerpc: Move C prototypes out of asm-prototypes.h

2022-03-08T11:06:25+00:00

We originally added asm-prototypes.h in commit 42f5b4cacd78 ("powerpc: Introduce asm-prototypes.h"). It's purpose was for prototypes of C functions that are only called from asm, in order to fix sparse warnings about missing prototypes. A few months later Nick added a different use case in commit 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm") for C prototypes for exported asm functions. This is basically the inverse of our original usage. Since then we've added various prototypes to asm-prototypes.h for both reasons, meaning we now need to unstitch it all. Dispatch prototypes of C functions into relevant headers and keep only the prototypes for functions defined in assembly. For the time being, leave prom_init() there because moving it into asm/prom.h or asm/setup.h conflicts with drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o This will be fixed later by untaggling asm/pci.h and asm/prom.h or by renaming the function in shadowrom.c Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/62d46904eca74042097acf4cb12c175e3067f3d1.1646413435.git.christophe.leroy@csgroup.eu

powerpc: smp: remove hack to obtain offset of task_struct::cpu

2021-09-30T14:13:11+00:00

Instead of relying on awful hacks to obtain the offset of the cpu field in struct task_struct, move it back into struct thread_info, which does not create the same level of circular dependency hell when trying to include the header file that defines it. Signed-off-by: Ard Biesheuvel Acked-by: Mark Rutland Acked-by: Michael Ellerman

powerpc/smp: Use existing L2 cache_map cpumask to find L3 cache siblings

2021-08-04T00:53:39+00:00

On POWER10 systems, the "ibm,thread-groups" property "2" indicates the cpus in thread-group share both L2 and L3 caches. Hence, use cache_property = 2 itself to find both the L2 and L3 cache siblings. Hence, create a new thread_group_l3_cache_map to keep list of L3 siblings, but fill the mask using same property "2" array. Signed-off-by: Parth Shah Reviewed-by: Gautham R. Shenoy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210728175607.591679-4-parth@linux.ibm.com

powerpc/cacheinfo: Lookup cache by dt node and thread-group id

2021-08-04T00:53:39+00:00

Currently the cacheinfo code on powerpc indexes the "cache" objects (modelling the L1/L2/L3 caches) where the key is device-tree node corresponding to that cache. On some of the POWER server platforms thread-groups within the core share different sets of caches (Eg: On SMT8 POWER9 systems, threads 0,2,4,6 of a core share L1 cache and threads 1,3,5,7 of the same core share another L1 cache). On such platforms, there is a single device-tree node corresponding to that cache and the cache-configuration within the threads of the core is indicated via "ibm,thread-groups" device-tree property. Since the current code is not aware of the "ibm,thread-groups" property, on the aforementoined systems, cacheinfo code still treats all the threads in the core to be sharing the cache because of the single device-tree node (In the earlier example, the cacheinfo code would says CPUs 0-7 share L1 cache). In this patch, we make the powerpc cacheinfo code aware of the "ibm,thread-groups" property. We indexe the "cache" objects by the key-pair (device-tree node, thread-group id). For any CPUX, for a given level of cache, the thread-group id is defined to be the first CPU in the "ibm,thread-groups" cache-group containing CPUX. For levels of cache which are not represented in "ibm,thread-groups" property, the thread-group id is -1. [parth: Remove "static" keyword for the definition of "thread_group_l1_cache_map" and "thread_group_l2_cache_map" to get rid of the compile error.] Signed-off-by: Gautham R. Shenoy Signed-off-by: Parth Shah Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210728175607.591679-2-parth@linux.ibm.com

powerpc/smp: Cache CPU to chip lookup

2021-04-17T00:40:51+00:00

On systems with large CPUs per node, even with the filtered matching of related CPUs, there can be large number of calls to cpu_to_chip_id for the same CPU. For example with 4096 vCPU, 1 node QEMU configuration, with 4 threads per core, system could be see upto 1024 calls to cpu_to_chip_id() for the same CPU. On a given system, cpu_to_chip_id() for a given CPU would always return the same. Hence cache the result in a lookup table for use in subsequent calls. Since all CPUs sharing the same core will belong to the same chip, the lookup_table has an entry for one CPU per core. chip_id_lookup_table is not being freed and would be used on subsequent CPU online post CPU offline. Reported-by: Daniel Henrique Barboza Suggested-by: Michael Ellerman Signed-off-by: Srikar Dronamraju Tested-by: Daniel Henrique Barboza Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210415120934.232271-4-srikar@linux.vnet.ibm.com

kernel/linux.git/arch/powerpc/include/asm/smp.h, branch linux-7.0.y

powerpc: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-uapi headers

powerpc/smp: Remap boot CPU onto core 0 if >= nr_cpu_ids

powerpc/cpu: Mark start_secondary_resume() __noreturn

powerpc/64: Move paca allocation to early_setup()

powerpc/smp: Remove unused inline functions

powerpc: Move C prototypes out of asm-prototypes.h

powerpc: smp: remove hack to obtain offset of task_struct::cpu

powerpc/smp: Use existing L2 cache_map cpumask to find L3 cache siblings

powerpc/cacheinfo: Lookup cache by dt node and thread-group id

powerpc/smp: Cache CPU to chip lookup

powerpc: Replace ASSEMBLY with ASSEMBLER in non-uapi headers