On 27.06.2017 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:
Pretty cool stuff! > > 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? As mentioned in patch #1, would it somehow be able to include code rather than copying it and maintaining it separately? > > - 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. ...)? Guess this is the way to go for now. > > - 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? Good question, I think all these solutions will require way more effort. > > Thomas -- Thanks, David