Hosts the 0x221E linux distro kernel. https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.7.y 2024-04-03T13:11:10Z 2024-04-03T13:11:10Z Michael Ellerman 2024-02-14T13:14:04Z urn:sha1:6a93e4b70462a85e1805f5bb930b0a0b577fed9e [ Upstream commit 777f81f0a9c780a6443bcf2c7785f0cc2e87c1ef ] If nr_cpu_ids is too low to include the boot CPU adjust nr_cpu_ids upward. Otherwise the kernel will BUG when trying to allocate a paca for the boot CPU and fail to boot. Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231229120107.2281153-2-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org> 2024-04-03T13:11:10Z Michael Ellerman 2024-02-14T13:14:04Z urn:sha1:4efadc432b470e2fff69929ff9cb33a363072afd [ Upstream commit 5580e96dad5a439d561d9648ffcbccb739c2a120 ] If nr_cpu_ids is too low to include at least all the threads of a single core adjust nr_cpu_ids upwards. This avoids triggering odd bugs in code that assumes all threads of a core are available. Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231229120107.2281153-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org> 2023-06-19T07:36:25Z Benjamin Gray 2023-06-19T07:36:25Z urn:sha1:0ffd60b782ed79349baf28dd3259c872f39274e9 ISA 3.1B introduces the Dynamic Execution Control Register (DEXCR). It is a per-cpu register that allows control over various CPU behaviours including branch hint usage, indirect branch speculation, and hashst/hashchk support. Add some definitions and basic support for the DEXCR in the kernel. Right now it just * Initialises the DEXCR and HASHKEYR to a fixed value when a CPU onlines. * Clears them in reset_sprs(). * Detects when the NPHIE aspect is supported (the others don't get looked at in this series, so there's no need to waste a CPU_FTR on them). We initialise the HASHKEYR to ensure that all cores have the same key, so an HV enforced NPHIE + swapping cores doesn't randomly crash a process using hash instructions. The stores to HASHKEYR are unconditional because the ISA makes no mention of the SPR being missing if support for doing the hashes isn't present. So all that would happen is the HASHKEYR value gets ignored. This helps slightly if NPHIE detection fails; e.g., we currently only detect it on pseries. Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> [mpe: Use simple values for DEXCR constants] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230616034846.311705-4-bgray@linux.ibm.com 2023-02-12T11:12:39Z Russell Currey 2023-02-10T08:03:58Z urn:sha1:91361b5175d2b3704f7e436d0071893c839e1199 Before interacting with the PLPKS, we ask the hypervisor to generate a password for the current boot, which is then required for most further PLPKS operations. If we kexec into a new kernel, the new kernel will try and fail to generate a new password, as the password has already been set. Pass the password through to the new kernel via the device tree, in /chosen/ibm,plpks-pw. Check for the presence of this property before trying to generate a new password - if it exists, use the existing password and remove it from the device tree. This only works with the kexec_file_load() syscall, not the older kexec_load() syscall, however if you're using Secure Boot then you want to be using kexec_file_load() anyway. Signed-off-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230210080401.345462-24-ajd@linux.ibm.com 2023-02-10T11:19:56Z Nicholas Piggin 2022-12-16T11:59:29Z urn:sha1:dc222fa7737212fe0da513e5b8937c156d02225d 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 <npiggin@gmail.com> [mpe: Fix build error on 32-bit] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20221216115930.2667772-4-npiggin@gmail.com 2022-12-07T22:43:15Z Michael Ellerman 2022-12-07T22:43:15Z urn:sha1:64fdcbcc064966bbf261bb455876dffa58858d32 Add an IS_ENABLED() check to fix the build error: arch/powerpc/kernel/prom.o: in function `early_init_dt_scan_cpus': prom.c:(.init.text+0x2ea): undefined reference to `boot_cpu_node_count' Fixes: e13d23a404f2 ("powerpc: export the CPU node count") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 2022-12-07T09:14:49Z Laurent Dufour 2022-11-10T18:06:18Z urn:sha1:e13d23a404f2e6dfaf8b1ef7d161a0836fce4fa5 At boot time, the FDT is parsed to compute the number of CPUs. In addition count the number of CPU nodes and export it. This is useful when building the FDT for a kexeced kernel since we need to take in account the CPU node added since the boot time during CPU hotplug operations. Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20221110180619.15796-2-ldufour@linux.ibm.com 2022-09-30T08:35:53Z Michael Ellerman 2022-09-30T08:27:07Z urn:sha1:541229707970ff2ad3f7705b1dbd025d7cc9bc48 Add the model of the machine we're on to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: IBM,8247-22L Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220930082709.55830-4-mpe@ellerman.id.au 2022-09-30T08:35:53Z Michael Ellerman 2022-09-30T08:27:06Z urn:sha1:48b7019b6abd029d3800620bb53f0ae3ca052441 If we detect a logical PVR add that to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: ... 0xf000004 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220930082709.55830-3-mpe@ellerman.id.au 2022-09-30T08:35:52Z Michael Ellerman 2022-09-30T08:27:05Z urn:sha1:bd649d40e0f2ffa1e16b4dbb93dc627177410e78 Add the PVR and CPU name to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: ... POWER8E (raw) 0x4b0201 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220930082709.55830-2-mpe@ellerman.id.au