qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly in


From: Viktor Mihajlovski
Subject: Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Date: Wed, 28 Jun 2017 17:02:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

On 28.06.2017 12:56, Thomas Huth wrote:
> On 28.06.2017 10:02, Thomas Huth wrote:
>> On 28.06.2017 09:28, Viktor Mihajlovski wrote:
>>> On 27.06.2017 23:40, Thomas Huth wrote:
>>> [...]
>>>>>> - Is it OK to require loading an .INS file first? Or does anybody
>>>>>>   have a better idea how to load multiple files (kernel, initrd,
>>>>>>   etc. ...)?
>>>>> It would be nice to support PXE-style boot, because the majority of boot
>>>>> servers is set up that way. A straightforward way would be to do a PXE
>>>>> emulation by attempting to download a pxelinux.cfg from the well-known
>>>>> locations, parsing the content (menu) and finally load the kernel,
>>>>> initrd and set the kernel command line as specified there. (I know, but
>>>>> you're already parsing the INS-File).
>>>>
>>>> Please, don't mix up PXE and pxelinux (since you've used both terms in
>>>> above paragraph). Assuming that you're only talking about pxlinux config
>>>> files... are they that common on s390x already? Using the pxelinux
>>>> config file syntax sounds like we would be completely bound to only
>>>> loading Linux guests to me, since the boot loader has to know where to
>>>> load the initrd and how to patch the kernel so that it can find the initrd.
>>>> Using .INS files sounds more flexible to me instead, since you can also
>>>> specify the addresses here - so you can theoretically also load other
>>>> guest kernels, and that's IMHO the better approach since a firmware
>>>> should stay as generic as possible.
>>>>
>>> In order to be consumable, the network boot should support the most
>>> common configurations. I would think that most network boot servers are
>>> setup as PXE boot servers using pxelinux configs.
>>
>> Are you really sure about the popularity of pxelinux? It's just one
>> flavor of secondary stage network boot loaders - which also only exist
>> on x86 so far, as far as I know.
> 
> And it seems like it also only works with legacy BIOSes, i.e. you can
> not use it on EFI-only systems, if I've got that right:
> 
> https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-Using-GRUB2
> 
> So I guess the significance of pxelinux will very likely decrease in
> the next years...
> 
Maybe, but supposed goners tend to linger more often than not. I.e., the
syslinux project offers a EFI bootloader called syslinux.efi equivalent
to the pexelinux.0 BIOS loader.
Further, the OPAL firmware of newer POWER systems embeds petitboot and
thus offers PXELINUX-compatible network boot as well.

I appreciate the idea of a proper BOOTP implementation though, so maybe
a compromise could be to start off with your proposal with the slight
modification that the final boot action is controlled by the bootfile
content (file magic), similar to what you suggested in order to support
both insfile and binary kernel. PXELINUX emulation could be triggered by
a specially crafted bootfile then. What do you think?
>  Thomas
> 


-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294




reply via email to

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