Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS

[Alexander Graf <agraf@suse.de>]

On 27.06.17 13:48, Thomas Huth wrote:
> It's already possible to do a network boot of an s390x guest with an
> external netboot image (based on a Linux installation), but it would
> be much more convenient if the s390-ccw firmware supported network
> booting right out of the box, without the need to assemble such an
> external image first.
> 
> This patch series now introduces network booting via DHCP and TFTP
> directly into the s390-ccw firmware by re-using the networking stack
> from the SLOF firmware (see https://github.com/aik/SLOF/ for details),
> and adds a driver for virtio-net-ccw devices.
> 
> Once the patches have been applied, you can download an .INS file
> via TFTP which contains the information about the further files
> that have to be loaded - kernel, initrd, etc. For example, you can
> use the built-in TFTP and DHCP server of QEMU for this by starting
> QEMU with:
> 
>   qemu-system-s390x ... -device virtio-net,netdev=n1,bootindex=1 \
>         -netdev user,id=n1,tftp=/path/to/tftp,bootfile=generic.ins
> 
> The .INS file has to use the same syntax as the .INS files that can
> already be found on s390x Linux distribution installation CD-ROMs.
> 
> 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?

I think 75k is still perfectly reasonable, yes.

> 
> - 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. ...)?
> 
> - 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 easily?
> 
> - 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?

IMHO the only viable next step would be to support UEFI and build on top 
of that - either by porting edk2 or U-Boot to s390x.

The problem with solutions like petitboot or home grown grub2 targets is 
that it becomes a documentation and knowledge sharing nightmare down the 
road. The less we're different from everyone else, the easier it becomes 
to maintain s390x.


Alex