lkml.org 
[lkml]   [2018]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: s390 qemu boot failure in -next
From
Date
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".
>
>

\
 
 \ /
  Last update: 2018-06-25 15:35    [W:1.089 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site