Messages in this thread | | | Subject | Re: s390 qemu boot failure in -next | From | Guenter Roeck <> | Date | Mon, 25 Jun 2018 06:35:30 -0700 |
| |
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@linux.ibm.com> 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". > >
| |