[Top][All Lists]

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

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

From: Guenter Roeck
Subject: Re: [Qemu-devel] s390 qemu boot failure in -next
Date: Mon, 25 Jun 2018 06:35:30 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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 <address@hidden> 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

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


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

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

reply via email to

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