s390 qemu boot failure in -next

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Also adding QEMU.

Quoted 22 lines · Christian Borntraeger

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

Quoted 7 lines

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Something like this in QEMU

hw/s390x/ipl.c +4 -2

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */
         if (pentry == KERN_IMAGE_START || pentry == 0x800) {
             ipl->start_addr = KERN_IMAGE_START;
-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
         } else {
             ipl->start_addr = pentry;
         }
+       if (ipl->cmdline) {
+            /* If there is a command line, put it in the right place */
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
+       }
 
         if (ipl->initrd) {
             ram_addr_t initrd_offset;

would put the command line in no matter what the start address is.

Quoted 53 lines · Christian Borntraeger

Also adding QEMU.

Quoted 22 lines · Christian Borntraeger

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

Quoted 7 lines

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Something like this in QEMU

hw/s390x/ipl.c +4 -2

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */
         if (pentry == KERN_IMAGE_START || pentry == 0x800) {
             ipl->start_addr = KERN_IMAGE_START;
-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
         } else {
             ipl->start_addr = pentry;
         }
+       if (ipl->cmdline) {
+            /* If there is a command line, put it in the right place */
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
+       }
 

Quoted 4 lines

hw/s390x/ipl.c +0 -0

         if (ipl->initrd) {
             ram_addr_t initrd_offset;

would put the command line in no matter what the start address is.

Ideally we would do 2 changes:
- change QEMU to add a commandline to 10480 if specified
- have a way to fix the kernel elf file to still boot with older QEMUs

Quoted 35 lines · Christian Borntraeger

Also adding QEMU.

Quoted 22 lines · Christian Borntraeger

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

Quoted 7 lines

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Something like this in QEMU

Quoted 6 lines

hw/s390x/ipl.c +0 -0

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */

hw/s390x/ipl.c static void s390_ipl_realize(DeviceState *dev, Error **errp) · line 195

Quoted 10 lines

hw/s390x/ipl.c +3 -2

         if (pentry == KERN_IMAGE_START || pentry == 0x800) {
             ipl->start_addr = KERN_IMAGE_START;
-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
         } else {
             ipl->start_addr = pentry;
         }
+       if (ipl->cmdline) {
+            /* If there is a command line, put it in the right place */
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);

Also adding QEMU.

Quoted 27 lines · Christian Borntraeger

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Quoted 2 lines

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Something like this in QEMU

hw/s390x/ipl.c +0 -0

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */
         if (pentry == KERN_IMAGE_START || pentry == 0x800) {

hw/s390x/ipl.c +0 -0

         if (ipl->initrd) {
             ram_addr_t initrd_offset;
 

would put the command line in no matter what the start address is.

Quoted 25 lines · On Mon, 25 Jun 2018 09:27:59 +0200 Christian Borntraeger…

Also adding QEMU.

Quoted 22 lines · Christian Borntraeger

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

Quoted 5 lines

Quoted 5 lines

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Do we consider these locations to be an exported interface, or is it just QEMU guessing?

Quoted 17 lines

Quoted 3 lines

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Something like this in QEMU

hw/s390x/ipl.c +0 -2

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */
         if (pentry == KERN_IMAGE_START || pentry == 0x800) {
             ipl->start_addr = KERN_IMAGE_START;
-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
         } else {

hw/s390x/ipl.c static void s390_ipl_realize(DeviceState *dev, Error **errp) · line 196

Quoted 6 lines

hw/s390x/ipl.c +4 -0

             ipl->start_addr = pentry;
         }
+       if (ipl->cmdline) {
+            /* If there is a command line, put it in the right place */
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
+       }

Check for the magic Linux string (like in the non-elf case) first?

Quoted 6 lines

hw/s390x/ipl.c +0 -0

         if (ipl->initrd) {
             ram_addr_t initrd_offset;
 

would put the command line in no matter what the start address is.

I'm for putting that one in (and backporting it to qemu-stable). It's a bit worrying, though, that our ipl code is so fragile...

Quoted 16 lines · Cornelia Huck

Quoted 13 lines · On Mon, 25 Jun 2018 09:27:59 +0200 Christian Borntraeger…

Something like this in QEMU

hw/s390x/ipl.c +0 -2

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */
         if (pentry == KERN_IMAGE_START || pentry == 0x800) {
             ipl->start_addr = KERN_IMAGE_START;
-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
         } else {

Quoted 8 lines

hw/s390x/ipl.c static void s390_ipl_realize(DeviceState *dev, Error **errp) · line 196

Quoted 6 lines

hw/s390x/ipl.c +4 -0

             ipl->start_addr = pentry;
         }
+       if (ipl->cmdline) {
+            /* If there is a command line, put it in the right place */
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
+       }  

Check for the magic Linux string (like in the non-elf case) first?

Even that does not exists in vmlinux but only in bzImage with the latest patchset (in next, but not upstream yet)

Quoted 9 lines

Quoted 6 lines

hw/s390x/ipl.c +0 -0

         if (ipl->initrd) {
             ram_addr_t initrd_offset;
 

would put the command line in no matter what the start address is.

I'm for putting that one in (and backporting it to qemu-stable). It's a bit worrying, though, that our ipl code is so fragile...

We actually have to combine this with Thomas fix (to check for rom_ptr returning something sane). It seems that ipl->commandline is always there, so we have to check for strlen!=0 it seems..

I mean if somebody ask for "-append something" we can certainly always write something if there is rom/ram.

Quoted 13 lines

Quoted 8 lines

Quoted 5 lines

 
         if (ipl->initrd) {
             ram_addr_t initrd_offset;

would put the command line in no matter what the start address is.

I'm for putting that one in (and backporting it to qemu-stable). It's a bit worrying, though, that our ipl code is so fragile...

We actually have to combine this with Thomas fix (to check for rom_ptr returning something sane). It seems that ipl->commandline is always there, so we have to check for strlen!=0 it seems..

Quoted 2 lines

I mean if somebody ask for "-append something" we can certainly always write something if there is rom/ram.

Given that the uncompressed image is not supposed to be bootable anymore, does it make sense to add this anyway?

I'll go ahead and queue Thomas' fix, though.

Quoted 30 lines · On Mon, 25 Jun 2018 09:27:59 +0200 Christian Borntraeger…

Also adding QEMU.

Quoted 27 lines · Christian Borntraeger

Quoted 10 lines · Guenter Roeck

Hi,

starting with commit 's390/boot: make head.S and als.c be part of the decompressor only' in -next, s390 immages no longer boot in qemu. As far as I can see, the reason is that the command line is no longer passed from qemu to the kernel, which results in a panic because the root file system can not be mounted.

Was this change made on purpose ? If so, is there a way to get qemu back to working ?

Certainly not on purpose.

Vasily, I can reproduce this with KVM and an external kernel boot of the vmlinux file (the elf file)

e.g.

qemu-system-s390 -enable-kvm -nographic -kernel vmlinux -append "this string no longer is command line"

The compressed image (bzImage) seems to work fine though.

This seems to be an unfortunate side effect of QEMUs ways to "guess" its Linux (checking for start address 0x10000, which is no longer true for the vmlinux file). With the pure vmlinux elf file the load address is 0x100000 as there is no unpacker.

Do we consider these locations to be an exported interface, or is it just QEMU guessing?

Quoted 12 lines

Quoted 2 lines

Guenter, can you check if arch/s390/boot/bzImage works for you as a workaround?

Something like this in QEMU

hw/s390x/ipl.c +0 -0

index f278036fa7..14153ce880 100644
@@ -187,11 +187,13 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
          */
         if (pentry == KERN_IMAGE_START || pentry == 0x800) {

hw/s390x/ipl.c static void s390_ipl_realize(DeviceState *dev, Error **errp) · line 196

Quoted 10 lines

hw/s390x/ipl.c +4 -2

             ipl->start_addr = KERN_IMAGE_START;
-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
         } else {
             ipl->start_addr = pentry;
         }
+       if (ipl->cmdline) {
+            /* If there is a command line, put it in the right place */
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
+       }

Check for the magic Linux string (like in the non-elf case) first?

Quoted 5 lines

hw/s390x/ipl.c +0 -0

         if (ipl->initrd) {
             ram_addr_t initrd_offset;
 

would put the command line in no matter what the start address is.

I'm for putting that one in (and backporting it to qemu-stable). It's a bit worrying, though, that our ipl code is so fragile...

This change has been done on purpose. Uncompressed image is not going to be bootable any more. In future the decompressor phase would get more function (early memory detection as an example) and there is no chance to duplicate that code in uncompressed image as well (to keep it bootable on its own). The patch series commit messages contain more technical details.

For qemu either bzImage or arch/s390/boot/compressed/vmlinux should be used, which are bootable images.

But that's really confusing that uncompressed vmlinux is still kind of booting. May be we should discuss how to avoid this confusion (may be change uncompressed image enty point to a function doing disabled wait with badb007 or smth) and how to encourage people to use arch/s390/boot/compressed/vmlinux instead.

Quoted 7 lines · On Mon, 25 Jun 2018 10:36:33 +0200 Vasily Gorbik <[email protected]> wrote:

This change has been done on purpose. Uncompressed image is not going to be bootable any more. In future the decompressor phase would get more function (early memory detection as an example) and there is no chance to duplicate that code in uncompressed image as well (to keep it bootable on its own). The patch series commit messages contain more technical details.

Quoted 8 lines

For qemu either bzImage or arch/s390/boot/compressed/vmlinux should be used, which are bootable images.

But that's really confusing that uncompressed vmlinux is still kind of booting. May be we should discuss how to avoid this confusion (may be change uncompressed image enty point to a function doing disabled wait with badb007 or smth) and how to encourage people to use arch/s390/boot/compressed/vmlinux instead.

So, the intention is that you can't boot the uncompressed image anywhere? (Was it possible before, e.g. when punching the image under z/VM?)

worried that it would break previously working setups (did we document the purpose of the images anywhere?)

Quoted 19 lines · Cornelia Huck

Quoted 15 lines · On Mon, 25 Jun 2018 10:36:33 +0200 Vasily Gorbik <[email protected]> wrote:

This change has been done on purpose. Uncompressed image is not going to be bootable any more. In future the decompressor phase would get more function (early memory detection as an example) and there is no chance to duplicate that code in uncompressed image as well (to keep it bootable on its own). The patch series commit messages contain more technical details.

For qemu either bzImage or arch/s390/boot/compressed/vmlinux should be used, which are bootable images.

But that's really confusing that uncompressed vmlinux is still kind of booting. May be we should discuss how to avoid this confusion (may be change uncompressed image enty point to a function doing disabled wait with badb007 or smth) and how to encourage people to use arch/s390/boot/compressed/vmlinux instead.

Quoted 3 lines

So, the intention is that you can't boot the uncompressed image anywhere? (Was it possible before, e.g. when punching the image under z/VM?)

The uncompressed image (the vmlinux file) was never bootable in LPAR or z/VM. It was just a "nice hack" that QEMU was able to do so. (even qemu on x86 can not boot the pure vmlinux file as far as I know).

I talked to Vasily and the vmlinux file in the linux source path is just an intermediate file. Future changes will happen that will make that ELF file unsuitable for direct boot anyway (e.g. think about potential ASLR or Kasan changes).

If yes, it would make sense to explicitly fence it. But I'm

Quoted 3 lines

worried that it would break previously working setups (did we document the purpose of the images anywhere?

I think by referring to arch/s390/boot/compressed/vmlinux things are probably good enough. That will still load from 0x10000.

We might still "change" the way that we add the parameters (e.g. make that not depend on the load address), but looking forward this might become less important for the "intermediate vmlnux file".

Quoted 16 lines · Christian Borntraeger

Quoted 13 lines · Cornelia Huck

Quoted 10 lines · On Mon, 25 Jun 2018 10:36:33 +0200 Vasily Gorbik <[email protected]> wrote:

This change has been done on purpose. Uncompressed image is not going to be bootable any more. In future the decompressor phase would get more function (early memory detection as an example) and there is no chance to duplicate that code in uncompressed image as well (to keep it bootable on its own). The patch series commit messages contain more technical details.

For qemu either bzImage or arch/s390/boot/compressed/vmlinux should be used, which are bootable images.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

But that's really confusing that uncompressed vmlinux is still kind of booting. May be we should discuss how to avoid this confusion (may be change uncompressed image enty point to a function doing disabled wait with badb007 or smth) and how to encourage people to use arch/s390/boot/compressed/vmlinux instead.

If an image is not expected to be bootable, a message such as "This image does not boot. Please use <correct image>" would be nice. Unfortunately, which image to boot under qemu is pretty much undocumented, and it is guesswork for each architecture/platform.

Guenter

Quoted 9 lines

I talked to Vasily and the vmlinux file in the linux source path is just an intermediate file. Future changes will happen that will make that ELF file unsuitable for direct boot anyway (e.g. think about potential ASLR or Kasan changes).

If yes, it would make sense to explicitly fence it. But I'm

Quoted 3 lines

worried that it would break previously working setups (did we document the purpose of the images anywhere?

Since uncompressed kernel image "vmlinux" elf file is not bootable under qemu anymore, add a check which would report that.

Qemu users are encouraged to use bzImage or
arch/s390/boot/compressed/vmlinux instead.

The check relies on s390 linux entry point ABI definition, which is only present in bzImage and arch/s390/boot/compressed/vmlinux.

Signed-off-by Vasily Gorbik <[email protected]>

---
 arch/s390/boot/head.S         |  4 ++--
 arch/s390/include/asm/setup.h |  3 ++-
 arch/s390/kernel/early.c      | 12 ++++++++++++
 3 files changed, 16 insertions(+), 3 deletions(-)

arch/s390/boot/head.S +2 -2

index f09e792df495..f721913b73f1 100644
@@ -272,14 +272,14 @@ iplstart:
 	.org	0x10000
 ENTRY(startup)
 	j	.Lep_startup_normal
-	.org	0x10008
+	.org	EP_OFFSET
 #
 # This is a list of s390 kernel entry points. At address 0x1000f the number of
 # valid entry points is stored.
 #
 # IMPORTANT: Do not change this table, it is s390 kernel ABI!
 #
-	.ascii	"S390EP"
+	.ascii	EP_STRING
 	.byte	0x00,0x01
 #
 # kdump startup-code at 0x10010, running in 64 bit absolute addressing mode

arch/s390/include/asm/setup.h +2 -1

index be02f0558048..1d66016f4170 100644
@@ -9,7 +9,8 @@
 #include <linux/const.h>
 #include <uapi/asm/setup.h>
 
-
+#define EP_OFFSET		0x10008
+#define EP_STRING		"S390EP"
 #define PARMAREA		0x10400
 #define PARMAREA_END		0x11000
 

arch/s390/kernel/early.c +12 -0

index 827699eb48fa..45c5be3d8777 100644
@@ -331,8 +331,20 @@ static void __init setup_boot_command_line(void)
 	append_to_cmdline(append_ipl_scpdata);
 }
 
+static void __init check_image_bootable(void)
+{
+	if (!memcmp(EP_STRING, (void *)EP_OFFSET, strlen(EP_STRING)))
+		return;
+
+	sclp_early_printk("The linux kernel boot failure: the image is corrupted or not bootable.\n");
+	sclp_early_printk("Please check that you are using bootable kernel image \"bzImage\".\n");
+	sclp_early_printk("(or alternatively \"arch/s390/boot/compressed/vmlinux\" image for qemu)\n");
+	disabled_wait(0xbadb007);
+}
+
 void __init startup_init(void)
 {
+	check_image_bootable();
 	time_early_init();
 	init_kernel_storage_key();
 	lockdep_off();

Signature · 2 lines

⣔⢻⣟⢢ 2.18.0.rc2.13.g4da9a5d
⣿⢿⡿⣿ pacman edition

Since uncompressed kernel image "vmlinux" elf file is not bootable under qemu anymore, add a check which would report that.

Qemu users are encouraged to use bzImage or
arch/s390/boot/compressed/vmlinux instead.

The check relies on s390 linux entry point ABI definition, which is only present in bzImage and arch/s390/boot/compressed/vmlinux.

Signed-off-by Vasily Gorbik <[email protected]>

Quoted 10 lines · Vasily Gorbik

Since uncompressed kernel image "vmlinux" elf file is not bootable under qemu anymore, add a check which would report that.

Qemu users are encouraged to use bzImage or
arch/s390/boot/compressed/vmlinux instead.

The check relies on s390 linux entry point ABI definition, which is only present in bzImage and arch/s390/boot/compressed/vmlinux.

Signed-off-by Vasily Gorbik <[email protected]>

Acked-by Christian Borntraeger <[email protected]>

some proposals regarding the wording below..

[...]

arch/s390/kernel/early.c static void __init setup_boot_command_line(void) · line 341

Quoted 4 lines

arch/s390/kernel/early.c +4 -0

+
+	sclp_early_printk("The linux kernel boot failure: the image is corrupted or not bootable.\n");
+	sclp_early_printk("Please check that you are using bootable kernel image \"bzImage\".\n");
+	sclp_early_printk("(or alternatively \"arch/s390/boot/compressed/vmlinux\" image for qemu)\n");  

What about making this explain things a bit more, e.g. something like

Linux kernel boot failure: The boot image does not contain all necessary components (like the entry point and decompressor). The plain vmlinux ELF file no longer carries all necessary parts for starting up. Please use bzImage or arch/s390/boot/compressed/vmlinux.

hw/s390x/ipl.c static void s390_ipl_realize(DeviceState *dev, Error **errp)

Quoted 4 lines · Christian Borntraeger

hw/s390x/ipl.c +1 -2

-            /* Overwrite parameters in the kernel image, which are "rom" */
-            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);
 
+            strcpy(rom_ptr(KERN_PARM_AREA), ipl->cmdline);

Why not replace strcpy() with strncpy() or snprintf()? strcpy() may overflow.