qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org,
	Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Eric Farman <farman@linux.vnet.ibm.com>,
	Farhan Ali <alifm@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Jens Freimann <jfreiman@redhat.com>,
	David Hildenbrand <david@redhat.com>
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	[thread overview]
Message-ID: <c664ff99-e98d-459d-2b07-306e0d00c5b7@redhat.com> (raw)
In-Reply-To: <23ec1642-053c-a15a-c03f-d9e48d1447e7@linux.vnet.ibm.com>

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	other threads:[~2017-06-27 21:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 11:48 [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 01/14] pc-bios/s390-ccw: Add the libc from the SLOF firmware Thomas Huth
2017-06-27 15:32   ` David Hildenbrand
2017-06-27 22:14     ` Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 02/14] pc-bios/s390-ccw: Start using the libc from SLOF Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 03/14] pc-bios/s390-ccw: Add a write() function for stdio Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 04/14] pc-bios/s390-ccw: Add implementation of sbrk() Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 05/14] pc-bios/s390-ccw: Add the TFTP network loading stack from SLOF Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 06/14] libnet: Remove remainders of netsave code Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 07/14] libnet: Rework error message printing Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 08/14] libnet: Refactor some code of netload() into a separate function Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 09/14] pc-bios/s390-ccw: Make the basic libnet code compilable Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 10/14] pc-bios/s390-ccw: Add timer code for the libnet Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 11/14] pc-bios/s390-ccw: Add virtio-net driver code Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 12/14] pc-bios/s390-ccw: Load file via an intermediate .INS file Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 13/14] pc-bios/s390-ccw: Allow loading to address 0 Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 14/14] pc-bios/s390-ccw: Wire up the netload code Thomas Huth
2017-06-27 15:41 ` [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS David Hildenbrand
2017-06-27 15:50 ` Viktor Mihajlovski
2017-06-27 21:40   ` Thomas Huth [this message]
2017-06-28  7:28     ` Viktor Mihajlovski
2017-06-28  8:02       ` Thomas Huth
2017-06-28 10:56         ` Thomas Huth
2017-06-28 15:02           ` Viktor Mihajlovski
2017-06-29  7:58             ` Thomas Huth
2017-06-29  8:10               ` Viktor Mihajlovski
2017-06-27 16:50 ` Farhan Ali
2017-06-28  7:34   ` Thomas Huth
2017-06-27 21:15 ` Alexander Graf
2017-06-27 21:56   ` Thomas Huth
2017-06-28  8:06     ` Gerd Hoffmann
2017-06-28  7:43 ` Christian Borntraeger
2017-06-28  8:59   ` Thomas Huth
2017-06-29  8:17     ` Thomas Huth
2017-06-29  8:39       ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c664ff99-e98d-459d-2b07-306e0d00c5b7@redhat.com \
    --to=thuth@redhat.com \
    --cc=agraf@suse.de \
    --cc=alifm@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=farman@linux.vnet.ibm.com \
    --cc=jfreiman@redhat.com \
    --cc=mihajlov@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).