Re: s390 qemu boot failure in -next

[Guenter Roeck]

On 06/25/2018 05:26 AM, Christian Borntraeger wrote:
> On 06/25/2018 10:49 AM, Cornelia Huck wrote:
> > On Mon, 25 Jun 2018 10:36:33 +0200
> > Vasily Gorbik <gor@xxxxxxxxxxxxx> 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.
> >
> > 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).

"even" is relative. vmlinux boots on some arm platforms, metag, mips64, nios2,
parisc, ppc/ppc64, and riscv.

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

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