Re: [PATCH] ppc64: add --reuse-cmdline parameter support
On 07/02/23 20:37, Simon Horman wrote: On Wed, Feb 01, 2023 at 02:23:31PM +0530, Sourabh Jain wrote: An option to copy the command line arguments from running kernel to kexec'd kernel. This option works for both kexec and kdump. In case --append= or --command-line= is provided along with --reuse-cmdline parameter then args listed against append and command-line parameter will be combined with command line argument from running kernel. Signed-off-by: Sourabh Jain Thanks for accepting the patch. - Sourabh Jain ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: question on microcode loading
Ccing x86 and more people.
On Wed, 8 Feb 2023 at 06:09, Steffen Nurpmeso wrote:
>
> Hello!
>
> First a thank you for kexec, i use it for a homegrown boot
> solution, where stage1 EFI_STUB kernel is used with busybox and
> cryptsetup to unlock an encrypted device, and then boots into
> stage2 via kexec -- a wonderful and easy solution that makes me
> happy (for years)!
>
> A bit lengthy now.
> There is only one question regarding CPU microcode loading: it
> seems the microcode is not "updated early" with kexec upon "boot".
> This is a homegrown kernel, with built-in firmware
>
> CONFIG_EXTRA_FIRMWARE="intel-ucode/06-8e-0a ..."
>
> but also with the firmware (prefix)in(g) the initrd
>
> {
> # Microcode update must be uncompressed and first
> [ -f ../../boot/early-ucode.cpio ] && ./$BB cat
> ../../boot/early-ucode.cpio
> # Followed by (possibly compressed) normal initrd
> ./$BB find . | ./$BB cpio -H newc -o | ./$BB gzip -9 -n
> } > ../.initrd
>
> (ie early-ucode.cpio exists) like here:
>
> #?0|kent:/boot# cpio -t <.kent.initrd.0
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/.enuineIntel.align.0123456789abc
> kernel/x86/microcode/GenuineIntel.bin
> 11020 blocks
> #?0|kent:/boot# dd if=.kent.initrd.0 skip=5642240 bs=1|gunzip|cpio -t
> .
> init
> linux-init-s1.sh
> sys
> run
> proc
> mnt
> dev
> dev/console
> bin
> bin/sh
> etc
> etc/mdev.sh
> etc/mdev.conf
> linux-init-lib.sh
> linux-init-s2.sh
> cryptsetup.static
> busybox.static
> 4491733+0 records in
> 4491733+0 records out
> 4491733 bytes (4.5 MB, 4.3 MiB) copied, 5.67558 s, 791 kB/s
> 18439 blocks
>
> If stage2 then boots it goes like
>
> Feb 6 17:38:15 (none) kernel: Linux version 6.1.9-ideapad (ports@kent)
> (gcc (CRUX-x86_64-multilib) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP
> PREEMPT_DYNAMIC Sat Feb 4 20:40:06 CET 2023
> Feb 6 17:38:15 (none) kernel: Command line: rtw88_pci.disable_aspm=1
> rc.hostname=kent
> Feb 6 17:38:15 (none) kernel: KERNEL supported cpus:
> Feb 6 17:38:15 (none) kernel: Intel GenuineIntel
> ...
> Feb 6 17:38:15 (none) kernel: Freeing SMP alternatives memory: 48K
> Feb 6 17:38:15 (none) kernel: smpboot: CPU0: Intel(R) Core(TM) i5-8250U
> CPU @ 1.60GHz (family: 0x6, model: 0x8e, stepping: 0xa)
> ..
> Feb 6 17:38:15 (none) kernel: node #0, CPUs: #1 #2 #3 #4
> Feb 6 17:38:15 (none) kernel: MDS CPU bug present and SMT on, data leak
> possible. See[..]
> Feb 6 17:38:15 (none) kernel: MMIO Stale Data CPU bug present and SMT on,
> data leak possible. See[..]
> Feb 6 17:38:15 (none) kernel: #5 #6 #7
> Feb 6 17:38:15 (none) kernel: smp: Brought up 1 node, 8 CPUs
> Feb 6 17:38:15 (none) kernel: smpboot: Max logical packages: 1
> Feb 6 17:38:15 (none) kernel: smpboot: Total of 8 processors activated
> (28811.00 BogoMIPS)
> ...
> Feb 6 17:38:15 (none) kernel: Unpacking initramfs...
> ...
> Feb 6 17:38:15 (none) kernel: Freeing initrd memory: 9900K
> ...
> Feb 6 17:38:16 (none) kernel: microcode: sig=0x806ea, pf=0x80,
> revision=0xf0
> Feb 6 17:38:16 (none) kernel: microcode: Microcode Update Driver: v2.2.
>
> Ie microcode comes late (SMT is later disabled) It (seems) ok
> after suspend/resume (due to
> Feb 7 01:30:12 (none) /root/bin/zzz.sh:
> echo mem > /sys/power/state
> Feb 7 20:11:26 (none) /root/bin/zzz.sh:
> echo off > /sys/devices/system/cpu/smt/control
> ):
>
> Feb 7 01:30:12 (none) kernel: PM: suspend entry (deep)
> ...
> Feb 7 20:11:23 (none) kernel: ACPI: PM: Preparing to enter system sleep
> state S3
> Feb 7 20:11:23 (none) kernel: ACPI: EC: event blocked
> Feb 7 20:11:23 (none) kernel: ACPI: EC: EC stopped
> Feb 7 20:11:23 (none) kernel: ACPI: PM: Saving platform NVS memory
> Feb 7 20:11:23 (none) kernel: Disabling non-boot CPUs ...
> Feb 7 20:11:23 (none) kernel: smpboot: CPU 1 is now offline
> Feb 7 20:11:23 (none) kernel: smpboot: CPU 2 is now offline
> Feb 7 20:11:23 (none) kernel: smpboot: CPU 3 is now offline
> Feb 7 20:11:23 (none) kernel: [Firmware Bug]: TSC ADJUST differs: CPU0 0
> --> -720144233. Restoring
> Feb 7 20:11:23 (none) kernel: microcode: microcode updated early to
> revision 0xf0, date = 2021-11-12
> Feb 7 20:11:23 (none) kernel: ACPI: PM: Low-level resume complete
>
> I wonder whether anything can be done about that.
>
> Thank you.
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
___
kexec mailing list
kexec@lists.infradead.org
question on microcode loading
Hello!
First a thank you for kexec, i use it for a homegrown boot
solution, where stage1 EFI_STUB kernel is used with busybox and
cryptsetup to unlock an encrypted device, and then boots into
stage2 via kexec -- a wonderful and easy solution that makes me
happy (for years)!
A bit lengthy now.
There is only one question regarding CPU microcode loading: it
seems the microcode is not "updated early" with kexec upon "boot".
This is a homegrown kernel, with built-in firmware
CONFIG_EXTRA_FIRMWARE="intel-ucode/06-8e-0a ..."
but also with the firmware (prefix)in(g) the initrd
{
# Microcode update must be uncompressed and first
[ -f ../../boot/early-ucode.cpio ] && ./$BB cat
../../boot/early-ucode.cpio
# Followed by (possibly compressed) normal initrd
./$BB find . | ./$BB cpio -H newc -o | ./$BB gzip -9 -n
} > ../.initrd
(ie early-ucode.cpio exists) like here:
#?0|kent:/boot# cpio -t <.kent.initrd.0
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
11020 blocks
#?0|kent:/boot# dd if=.kent.initrd.0 skip=5642240 bs=1|gunzip|cpio -t
.
init
linux-init-s1.sh
sys
run
proc
mnt
dev
dev/console
bin
bin/sh
etc
etc/mdev.sh
etc/mdev.conf
linux-init-lib.sh
linux-init-s2.sh
cryptsetup.static
busybox.static
4491733+0 records in
4491733+0 records out
4491733 bytes (4.5 MB, 4.3 MiB) copied, 5.67558 s, 791 kB/s
18439 blocks
If stage2 then boots it goes like
Feb 6 17:38:15 (none) kernel: Linux version 6.1.9-ideapad (ports@kent) (gcc
(CRUX-x86_64-multilib) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP
PREEMPT_DYNAMIC Sat Feb 4 20:40:06 CET 2023
Feb 6 17:38:15 (none) kernel: Command line: rtw88_pci.disable_aspm=1
rc.hostname=kent
Feb 6 17:38:15 (none) kernel: KERNEL supported cpus:
Feb 6 17:38:15 (none) kernel: Intel GenuineIntel
...
Feb 6 17:38:15 (none) kernel: Freeing SMP alternatives memory: 48K
Feb 6 17:38:15 (none) kernel: smpboot: CPU0: Intel(R) Core(TM) i5-8250U CPU
@ 1.60GHz (family: 0x6, model: 0x8e, stepping: 0xa)
..
Feb 6 17:38:15 (none) kernel: node #0, CPUs: #1 #2 #3 #4
Feb 6 17:38:15 (none) kernel: MDS CPU bug present and SMT on, data leak
possible. See[..]
Feb 6 17:38:15 (none) kernel: MMIO Stale Data CPU bug present and SMT on,
data leak possible. See[..]
Feb 6 17:38:15 (none) kernel: #5 #6 #7
Feb 6 17:38:15 (none) kernel: smp: Brought up 1 node, 8 CPUs
Feb 6 17:38:15 (none) kernel: smpboot: Max logical packages: 1
Feb 6 17:38:15 (none) kernel: smpboot: Total of 8 processors activated
(28811.00 BogoMIPS)
...
Feb 6 17:38:15 (none) kernel: Unpacking initramfs...
...
Feb 6 17:38:15 (none) kernel: Freeing initrd memory: 9900K
...
Feb 6 17:38:16 (none) kernel: microcode: sig=0x806ea, pf=0x80, revision=0xf0
Feb 6 17:38:16 (none) kernel: microcode: Microcode Update Driver: v2.2.
Ie microcode comes late (SMT is later disabled) It (seems) ok
after suspend/resume (due to
Feb 7 01:30:12 (none) /root/bin/zzz.sh:
echo mem > /sys/power/state
Feb 7 20:11:26 (none) /root/bin/zzz.sh:
echo off > /sys/devices/system/cpu/smt/control
):
Feb 7 01:30:12 (none) kernel: PM: suspend entry (deep)
...
Feb 7 20:11:23 (none) kernel: ACPI: PM: Preparing to enter system sleep
state S3
Feb 7 20:11:23 (none) kernel: ACPI: EC: event blocked
Feb 7 20:11:23 (none) kernel: ACPI: EC: EC stopped
Feb 7 20:11:23 (none) kernel: ACPI: PM: Saving platform NVS memory
Feb 7 20:11:23 (none) kernel: Disabling non-boot CPUs ...
Feb 7 20:11:23 (none) kernel: smpboot: CPU 1 is now offline
Feb 7 20:11:23 (none) kernel: smpboot: CPU 2 is now offline
Feb 7 20:11:23 (none) kernel: smpboot: CPU 3 is now offline
Feb 7 20:11:23 (none) kernel: [Firmware Bug]: TSC ADJUST differs: CPU0 0 -->
-720144233. Restoring
Feb 7 20:11:23 (none) kernel: microcode: microcode updated early to revision
0xf0, date = 2021-11-12
Feb 7 20:11:23 (none) kernel: ACPI: PM: Low-level resume complete
I wonder whether anything can be done about that.
Thank you.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 5/7] kexec: exclude hot remove cpu from elfcorehdr notes
On 2/1/23 05:33, Thomas Gleixner wrote:
Eric!
On Tue, Jan 31 2023 at 17:42, Eric DeVolder wrote:
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -366,6 +366,14 @@ int crash_prepare_elf64_headers(struct kimage *image,
struct crash_mem *mem,
/* Prepare one phdr of type PT_NOTE for each present CPU */
for_each_present_cpu(cpu) {
+#ifdef CONFIG_CRASH_HOTPLUG
+ if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) {
+ /* Skip the soon-to-be offlined cpu */
+ if ((image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU) &&
+ (cpu == image->offlinecpu))
+ continue;
+ }
+#endif
I'm failing to see how the above is correct in any way. Look at the
following sequence of events:
1) Offline CPU$N
-> Prepare elf headers with CPU$N excluded
2) Another hotplug operation != 'Online CPU$N'
-> Prepare elf headers with CPU$N included
Also in case of loading the crash kernel in the situation where not all
present CPUs are online (think boot time SMT disable) then your
resulting crash image will contain all present CPUs and none of the
offline CPUs are excluded.
How does that make any sense at all?
This image->hp_action and image->offlinecpu dance is engineering
voodoo. You just can do:
for_each_present_cpu(cpu) {
if (!cpu_online(cpu))
continue;
do_stuff(cpu);
which does the right thing in all situations and can be further
simplified to:
for_each_online_cpu(cpu) {
do_stuff(cpu);
without the need for ifdefs or whatever.
No?
Thanks,
tglx
Thomas,
I've been re-examining the cpuhp framework and understand a bit better its
operation.
Up until now, this patch series has been using either CPUHP_AP_ONLINE_DYN
or more recently CPUHP_BP_PREPARE_DYN with the same handler for both the
startup and teardown callbacks. This resulted in the cpu state, as seen by
my handler, as being incorrect in one direction or the other. For example,
when using CPUHP_AP_ONLINE_DYN, cpu_online() always resulted in 1 for the
cpu in my callback, even during tear down. For CPUHP_BP_PREPARE_DYN,
cpu_online() always resulted in 0. Thus the offlinecpu voodoo.
But no more!
The reason, as I now understand, is simple. A cpu will not show as online
until after state CPUHP_BRINGUP_CPU (when working from CPUHP_OFFLINE towards
CPUHP_ONLINE). And a cpu will not show as offline until after state
CPUHP_TEARDOWN_CPU (when working reverse order from CPUHP_ONLINE to
CPUHP_OFFLINE).
The CPUHP_BRINGUP_CPU is the last state of the PREPARE section, and boots
the new cpu. It is code running on the booting cpu that marks itself as
online.
CPUHP_BRINGUP_CPU
.startup()
bringup_cpu()
__cpu_up()
smp_ops.cpu_up()
native_cpu_up()
do_boot_cpu()
= on new cpu! =
start_secondary()
set_cpu_online(true)
There are quite a few CPUHP_..._STARTING states before the cpu is in a
productive state.
The CPUHP_TEARDOWN_CPU is the last state in the STARTING section, and takes the
cpu down.
Work/irqs are removed from this cpu and re-assigned to others.
CPUHP_TEARDOWN_CPU
.teardown()
takedown_cpu()
take_cpu_down()
__cpu_disable()
smp_ops.cpu_disable()
native_cpu_disable()
cpu_disable_common()
remove_cpu_from_maps()
set_cpu_online(false)
So my latest solution is introduce two new CPUHP states,
CPUHP_AP_ELFCOREHDR_ONLINE
for onlining and CPUHP_BP_ELFCOREHDR_OFFLINE for offlining. I'm open to better
names.
The CPUHP_AP_ELFCOREHDR_ONLINE needs to be placed after CPUHP_BRINGUP_CPU. My
attempts at locating this state failed when inside the STARTING section, so I
located
this just inside the ONLINE sectoin. The crash hotplug handler is registered on
this state as the callback for the .startup method.
The CPUHP_BP_ELFCOREHDR_OFFLINE needs to be placed before CPUHP_TEARDOWN_CPU,
and I
placed it at the end of the PREPARE section. This crash hotplug handler is also
registered on this state as the callback for the .teardown method.
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 6c6859bfc454..52d2db4d793e 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -131,6 +131,7 @@ enum cpuhp_state {
CPUHP_ZCOMP_PREPARE,
CPUHP_TIMERS_PREPARE,
CPUHP_MIPS_SOC_PREPARE,
+ CPUHP_BP_ELFCOREHDR_OFFLINE,
CPUHP_BP_PREPARE_DYN,
CPUHP_BP_PREPARE_DYN_END= CPUHP_BP_PREPARE_DYN + 20,
CPUHP_BRINGUP_CPU,
@@ -205,6 +206,7 @@ enum cpuhp_state {
/* Online section invoked on the hotplugged CPU from the hotplug thread */
CPUHP_AP_ONLINE_IDLE,
+ CPUHP_AP_ELFCOREHDR_ONLINE,
CPUHP_AP_SCHED_WAIT_EMPTY,
CPUHP_AP_SMPBOOT_THREADS,
CPUHP_AP_X86_VDSO_VMA_ONLINE,
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index
Re: [PATCH] kexec: make -a the default
On Fri, Feb 03, 2023 at 12:10:18AM +0100, Ahelenia Ziemiańska wrote: > AFAICT, there's no downside to this, and running into this each time > I want to kexec (and, presumably, a significant chunk of the population, > since lockdown is quite popular) on some machines, > then going to the manual, then finding out I want the /auto/ flag(!) > is quite annoying: > # kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd > /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline > kexec_load failed: Operation not permitted > entry = 0x46eff7760 flags = 0x3e > nr_segments = 7 > segment[0].buf = 0x557cd303efa0 > segment[0].bufsz = 0x70 > segment[0].mem = 0x10 > segment[0].memsz = 0x1000 > segment[1].buf = 0x557cd3046fe0 > segment[1].bufsz = 0x190 > segment[1].mem = 0x101000 > segment[1].memsz = 0x1000 > segment[2].buf = 0x557cd303f6e0 > segment[2].bufsz = 0x30 > segment[2].mem = 0x102000 > segment[2].memsz = 0x1000 > segment[3].buf = 0x7f658fa37010 > segment[3].bufsz = 0x12a51b5 > segment[3].mem = 0x46a55a000 > segment[3].memsz = 0x12a6000 > segment[4].buf = 0x7f6590ce1210 > segment[4].bufsz = 0x7e99e0 > segment[4].mem = 0x46b80 > segment[4].memsz = 0x377c000 > segment[5].buf = 0x557cd3039350 > segment[5].bufsz = 0x42fa > segment[5].mem = 0x46eff2000 > segment[5].memsz = 0x5000 > segment[6].buf = 0x557cd3032000 > segment[6].bufsz = 0x70e0 > segment[6].mem = 0x46eff7000 > segment[6].memsz = 0x9000 > > Closes: https://bugs.debian.org/1030248 > Signed-off-by: Ahelenia Ziemiańska Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] ppc64: add --reuse-cmdline parameter support
On Wed, Feb 01, 2023 at 02:23:31PM +0530, Sourabh Jain wrote: > An option to copy the command line arguments from running kernel > to kexec'd kernel. This option works for both kexec and kdump. > > In case --append= or --command-line= is provided along > with --reuse-cmdline parameter then args listed against append and > command-line parameter will be combined with command line argument > from running kernel. > > Signed-off-by: Sourabh Jain Thanks, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
