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
