This patch series adds kdump support for the s390 architecture (64 bit). There are a few common code changes necessary because the s390 implementation is different to other architectures in some points. Especially these common code patches (1-7) should be reviewed. Patch 8 "s390: kdump backend code" contains the s390 specific part. Patch 9 includes the necessary changes for the kexec tool. In the following I describe the main differences of the s390 implementation: The s390 kernel is not relocatable therefore the crashkernel memory is swapped with the area [0 - crashkernel memory] before the kdump kernel is started. Architectures other than s390 run the kdump kernel at a memory location that is disjunct to the standard location for the kernel image and to all memory that might be in use for I/O by the production system. The main reason for this seems to be that these architectures do not have a means to clear all ongoing I/O. If active memory of the production system is reused by the kdump kernel they run into memory corruption issues. On s390 with diagnose call 308 or boot (IPL) there is the possibility to stop all ongoing I/O. Therefore we can safely run the kdump kernel at the old location. On s390 we do not create page tables for the crashkernel memory and use a memcpy_real() function to load the kdump kernel and ramdisk in kexec_load() system call. On s390 we have external kdump triggers. For example stand-alone dump tools. The address range information of crashkernel memory is stored at a well defined storage location that can be used by the external dump triggers to find the kdump entry point. To export the address range for the crashkernel memory we introduce a new mechanism that we call meminfo. This allows to define checksum secured information in memory that is accessible via an s390 ABI defined storage address. The following information is currently stored via meminfo: * Crashkernel memory range * kexec segments for kdump * Pointer to vmcoreinfo note Checksums for the loaded kexec segments are stored. This can be used to verify that kdump is not corrupted. The check is done e.g. by the s390 stand-alone dump tools via meminfo. If kdump has NOT been overwritten, the checksums are valid and kdump is started, otherwise a full-blown s390 stand-alone dump is created as backup dump mechanism. On s390 the ELF header is created dynamically at kdump startup in the kdump (2nd) kernel. This is possible, because the memory detection and collection of the CPU register sets can be done on s390 in the 2nd kernel. Therefore on s390 the ELF header is NOT prepared by the kexec tool. The address for vmcoreinfo can be found via meminfo and is used by the kdump kernel for ELF header initialization. On s390 no additional kernel parameter is needed for kdump. Everything kdump needs to know can be determined dynamically when the 2nd kernel starts. If you agree with the approach of this patch series, how should this go upstream? Thanks, Michael
