Hi David,
> My concern is that we'll now have
>
> bool is_kdump_kernel(void)
> {
> return oldmem_data.start && !is_ipl_type_dump();
> }
>
> Which matches 3), but if 2) is also called "kdump", then should it actually
> be
>
> bool is_kdump_kernel(void)
> {
> return oldmem_data.start;
> }
>
> ?
>
> When I wrote that code I was rather convinced that the variant in this patch
> is the right thing to do.
A short explanation about what a stand-alone kdump is.
* First, it's not really a _regular_ kdump activated with kexec-tools and
executed by Linux itself but a regular stand-alone dump (SCSI) from the
FW's perspective (one has to use HMC or dumpconf to execute it and not
with kexec-tools like for the _regular_ kdump).
* One has to reserve crashkernel memory region in the old crashed kernel
even if it remains unused until the dump starts.
* zipl uses regular kdump kernel and initramfs to create stand-alone
dumper images and to write them to a dump disk which is used for
IPLIng the stand-alone dumper.
* The zipl bootloader takes care of transferring the old kernel memory
saved in HSA by the FW to the crashkernel memory region reserved by the old
crashed kernel before it enters the dumper. The HSA memory is released
by the zipl bootloader _before_ the dumper image is entered,
therefore, we cannot use HSA to read old kernel memory, and instead
use memory from crashkernel region, just like the regular kdump.
* is_ipl_type_dump() will be true for a stand-alone kdump because we IPL
the dumper like a regular stand-alone dump (e.g. zfcpdump).
* Summarized, zipl bootloader prepares an environment which is expected by
the regular kdump for a stand-alone kdump dumper before it is entered.
In my opinion, the correct version of is_kdump_kernel() would be
bool is_kdump_kernel(void)
{
return oldmem_data.start;
}
because Linux kernel doesn't differentiate between both the regular
and the stand-alone kdump where it matters while performing dumper
operations (e.g. reading saved old kernel memory from crashkernel memory region).
Furthermore, if i'm not mistaken then the purpose of is_kdump_kernel()
is to tell us whether Linux kernel runs in a kdump like environment and not
whether the current mode is identical to the proper and true kdump,
right ? And if stand-alone kdump swims like a duck, quacks like one, then it
is one, regardless how it was started, by kexecing or IPLing
from a disk.
The stand-alone kdump has a very special use case which most users will
never encounter. And usually, one just takes zfcpdump instead which is
more robust and much smaller considering how big kdump initrd can get.
stand-alone kdump dumper images cannot exceed HSA memory limit on a Z machine.
Regards
Alex
