kernel/arch/s390/include/asm/ipl.h, branch linux-5.14.y

s390/nvme: support firmware-assisted dump to NVMe disks

2020-10-02T12:40:48Z

From the kernel perspective NVMe dump works exactly like zFCP dump. Therefore, adapt all places where code explicitly tests only for IPL of type FCP DUMP. And also set the memory end correctly in this case. Signed-off-by: Alexander Egorenkov Reviewed-by: Vasily Gorbik Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik

s390: nvme dump support

2020-10-02T12:40:48Z

Add the nvme dump ipl type, associated data, and sysfs entries. This allows booting into a stand alone dump environment that resides on an nvme device. Signed-off-by: Jason J. Herne Signed-off-by: Vasily Gorbik

s390: nvme ipl

2020-05-06T13:19:35Z

Recognize IPL Block's Ipl Type of "nvme". Populate related structs and sysfs entries. Signed-off-by: Jason J. Herne Signed-off-by: Vasily Gorbik

s390/ipl: add support to control memory clearing for FCP and CCW re-IPL

2020-03-23T12:41:54Z

Re-IPL for both CCW and FCP is currently done by using diag 308 with the "Load Clear" subcode, which means that all memory will be cleared. This can increase re-IPL duration considerably on very large machines. For CCW devices, there is also a "Load Normal" subcode that was only used for dump kernels so far. For FCP devices, a similar "Load Normal" subcode was introduced with z14. The "Load Normal" diag 308 subcode allows to re-IPL without clearing memory. This patch adds a new "clear" sysfs attribute to /sys/firmware/reipl for both the ccw and fcp subdirectories, which can be set to either "0" or "1" to disable or enable re-IPL with memory clearing. The default value is "0", which disables memory clearing. Signed-off-by: Gerald Schaefer Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390/kernel: introduce .dma sections

2019-04-29T08:47:10Z

With a relocatable kernel that could reside at any place in memory, code and data that has to stay below 2 GB needs special handling. This patch introduces .dma sections for such text, data and ex_table. The sections will be part of the decompressor kernel, so they will not be relocated and stay below 2 GB. Their location is passed over to the decompressed / relocated kernel via the .boot.preserved.data section. The duald and aste for control register setup also need to stay below 2 GB, so move the setup code from arch/s390/kernel/head64.S to arch/s390/boot/head.S. The duct and linkage_stack could reside above 2 GB, but their content has to be preserved for the decompresed kernel, so they are also moved into the .dma section. The start and end address of the .dma sections is added to vmcoreinfo, for crash support, to help debugging in case the kernel crashed there. Signed-off-by: Gerald Schaefer Reviewed-by: Philipp Rudo Signed-off-by: Martin Schwidefsky

s390/kexec_file: Create ipl report and pass to next kernel

2019-04-29T08:44:02Z

Signed-off-by: Philipp Rudo Signed-off-by: Martin Schwidefsky

s390/ipl: add helper functions to create an IPL report

2019-04-26T10:34:05Z

PR: Adjusted to the use in kexec_file later. Signed-off-by: Martin Schwidefsky Signed-off-by: Philipp Rudo Signed-off-by: Martin Schwidefsky

s390/ipl: provide uapi header for list directed IPL

2019-04-26T10:34:05Z

The IPL parameter block is used as an interface between Linux and the machine to query and change the boot device and boot options. To be able to create IPL parameter block in user space and pass it as segment to kexec provide an uapi header with proper structure definitions for the block. Signed-off-by: Martin Schwidefsky

s390/ipl: make ipl_info less confusing

2019-04-26T10:34:05Z

The ipl_info union in struct ipl_parameter_block has the same name as the struct ipl_info. This does not help while reading the code and the union in struct ipl_parameter_block does not need to be named. Drop the name from the union. Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390: move ipl block to .boot.preserved.data section

2019-04-10T15:47:11Z

.boot.preserved.data is a better fit for ipl block than .boot.data which is discarded after init. Reusing .boot.preserved.data allows to simplify code a little bit and avoid copying data from .boot.data to persistent variables. Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky