[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180626102954.73965b42.cohuck@redhat.com>
Date: Tue, 26 Jun 2018 10:29:54 +0200
From: Cornelia Huck <cohuck@...hat.com>
To: Christian Borntraeger <borntraeger@...ibm.com>
Cc: Guenter Roeck <linux@...ck-us.net>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
qemu-s390x <qemu-s390x@...gnu.org>,
qemu-devel <qemu-devel@...gnu.org>,
Thomas Huth <thuth@...hat.com>
Subject: Re: s390 qemu boot failure in -next
On Mon, 25 Jun 2018 10:29:46 +0200
Christian Borntraeger <borntraeger@...ibm.com> wrote:
> On 06/25/2018 10:05 AM, Cornelia Huck wrote:
> > On Mon, 25 Jun 2018 09:27:59 +0200
> > Christian Borntraeger <borntraeger@...ibm.com> 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.
Powered by blists - more mailing lists