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: Thomas Huth
Subject: Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Date: Tue, 27 Jun 2017 23:40:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 27.06.2017 17:50, Viktor Mihajlovski wrote:
> On 27.06.2017 13:48, Thomas Huth wrote:
[...]
>> The patches are still in a rough shape, but before I continue here,
>> I though I'd get some feedback first. Specifically:
>>
>> - This adds a lot of additional code to the s390-ccw firmware (and
>>   the binary is afterwards three times as big as before, 75k instead
>>   of 25k) ... is that still acceptable?
> The size may be less of an issue than the general overhead for
> initialization.

Which concerns with regards to overhead do you have here? Startup time?
As far as I can tell, that's not an issue here - the firmware still
starts very fast.

> Since the current approach of the s390-ccw firmware of
> lazy loading (only if a network boot is requested) takes care of that,
> would it be conceivable that you build a standalone network boot
> firmware image instead of incorporating that into the base firmware?

That would shoot down the big advantage of this approach: Not to have to
fiddle with multiple firmware images - which is my main motivation here.
I'd like to avoid that we have to create yet another firmware package in
the distros. (Otherwise, what's the purpose of this when putting it into
yet another binary? We could then simply continue the current approach
with the Linux binary instead)

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

> Alternatively, one could load a single boot image (consisting of kernel
> and initrd concatenated, i.e. the bootable ISO format). This could serve
> as a more potent "stage 2" boot loader.

Agreed, that's also a common practice when doing network booting. I
guess the firmware could also support both quite easily, direct single
boot images, and .INS files. The latter could be detected via the file
name or with the magic string "* " at the beginning.

>> - The code from SLOF uses a different coding style (TABs instead
>>   of space) ... is it OK to keep that coding style here so we
>>   can share patches between SLOF and s390-ccw more easil>
>> - The code only supports TFTP (via UDP) ... I think that is OK for
>>   most use-cases, but if we ever want to support network booting
>>   via HTTP or something else that is based on TCP, we would need to
>>   use something else instead... Should we maybe rather head towards
>>   grub2, petitboot or something different instead?
> I don't have an opinion on whether HTTP, FTP, etc is needed, but at some
> point in time it would definitely be cool to have IPv6 support. Not sure
> whether SLOF has that included.

Yes, IPv6 is included in this networking stack.

 Thomas



reply via email to

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