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