qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [Qemu-devel] s390 qemu boot failure in -next
Date: Tue, 26 Jun 2018 10:29:54 +0200

On Mon, 25 Jun 2018 10:29:46 +0200
Christian Borntraeger <address@hidden> wrote:

> On 06/25/2018 10:05 AM, Cornelia Huck wrote:
> > On Mon, 25 Jun 2018 09:27:59 +0200
> > Christian Borntraeger <address@hidden> wrote:

> >> 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?  
> 
> Even that does not exists in vmlinux but only in bzImage with the latest 
> patchset
> (in next, but not upstream yet)

Ok.

> >   
> >>  
> >>          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.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]