Re: [Qemu-devel] s390 qemu boot failure in -next

[Vasily Gorbik]

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.

On Mon, Jun 25, 2018 at 10:05:48AM +0200, Cornelia Huck wrote:
> On Mon, 25 Jun 2018 09:27:59 +0200
> Christian Borntraeger <address@hidden> wrote:
> 
> > Also adding QEMU.
> > 
> > On 06/25/2018 09:10 AM, Christian Borntraeger wrote:
> > > 
> > > 
> > > On 06/22/2018 09:47 PM, Guenter Roeck wrote:  
> > >> 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?
> 
> > > 
> > > Guenter, can you check if arch/s390/boot/bzImage works for you as a 
> > > workaround?  
> > 
> > Something like this in QEMU 
> > 
> > diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
> > index f278036fa7..14153ce880 100644
> > --- a/hw/s390x/ipl.c
> > +++ b/hw/s390x/ipl.c
> > @@ -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);
> > +       }
> 
> Check for the magic Linux string (like in the non-elf case) first?
> 
> >  
> >          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...
>