configure | 6 +- hw/s390x/ipl.c | 2 +- pc-bios/s390-ccw/Makefile | 14 +- pc-bios/s390-ccw/bootmap.c | 10 +- pc-bios/s390-ccw/bootmap.h | 1 + pc-bios/s390-ccw/libc/Makefile | 47 ++ pc-bios/s390-ccw/libc/README.txt | 49 ++ pc-bios/s390-ccw/libc/ctype/Makefile.inc | 21 + pc-bios/s390-ccw/libc/ctype/isdigit.c | 25 + pc-bios/s390-ccw/libc/ctype/isprint.c | 18 + pc-bios/s390-ccw/libc/ctype/isspace.c | 29 + pc-bios/s390-ccw/libc/ctype/isxdigit.c | 21 + pc-bios/s390-ccw/libc/ctype/tolower.c | 18 + pc-bios/s390-ccw/libc/ctype/toupper.c | 21 + pc-bios/s390-ccw/libc/include/ctype.h | 24 + pc-bios/s390-ccw/libc/include/errno.h | 34 + pc-bios/s390-ccw/libc/include/limits.h | 32 + pc-bios/s390-ccw/libc/include/stdarg.h | 22 + pc-bios/s390-ccw/libc/include/stdbool.h | 20 + pc-bios/s390-ccw/libc/include/stddef.h | 25 + pc-bios/s390-ccw/libc/include/stdint.h | 28 + pc-bios/s390-ccw/libc/include/stdio.h | 63 ++ pc-bios/s390-ccw/libc/include/stdlib.h | 34 + pc-bios/s390-ccw/libc/include/string.h | 37 ++ pc-bios/s390-ccw/libc/include/sys/socket.h | 53 ++ pc-bios/s390-ccw/libc/include/unistd.h | 28 + pc-bios/s390-ccw/libc/stdio/Makefile.inc | 24 + pc-bios/s390-ccw/libc/stdio/fileno.c | 19 + pc-bios/s390-ccw/libc/stdio/fprintf.c | 26 + pc-bios/s390-ccw/libc/stdio/printf.c | 27 + pc-bios/s390-ccw/libc/stdio/putc.c | 25 + pc-bios/s390-ccw/libc/stdio/putchar.c | 21 + pc-bios/s390-ccw/libc/stdio/puts.c | 28 + pc-bios/s390-ccw/libc/stdio/setvbuf.c | 28 + pc-bios/s390-ccw/libc/stdio/sprintf.c | 30 + pc-bios/s390-ccw/libc/stdio/stdchnls.c | 23 + pc-bios/s390-ccw/libc/stdio/vfprintf.c | 27 + pc-bios/s390-ccw/libc/stdio/vsnprintf.c | 298 +++++++++ pc-bios/s390-ccw/libc/stdio/vsprintf.c | 19 + pc-bios/s390-ccw/libc/stdlib/Makefile.inc | 23 + pc-bios/s390-ccw/libc/stdlib/atoi.c | 18 + pc-bios/s390-ccw/libc/stdlib/atol.c | 18 + pc-bios/s390-ccw/libc/stdlib/error.c | 15 + pc-bios/s390-ccw/libc/stdlib/free.c | 26 + pc-bios/s390-ccw/libc/stdlib/malloc.c | 157 +++++ pc-bios/s390-ccw/libc/stdlib/malloc_defs.h | 16 + pc-bios/s390-ccw/libc/stdlib/memalign.c | 26 + pc-bios/s390-ccw/libc/stdlib/rand.c | 29 + pc-bios/s390-ccw/libc/stdlib/realloc.c | 40 ++ pc-bios/s390-ccw/libc/stdlib/strtol.c | 115 ++++ pc-bios/s390-ccw/libc/stdlib/strtoul.c | 105 ++++ pc-bios/s390-ccw/libc/string/Makefile.inc | 23 + pc-bios/s390-ccw/libc/string/memchr.c | 29 + pc-bios/s390-ccw/libc/string/memcmp.c | 30 + pc-bios/s390-ccw/libc/string/memcpy.c | 27 + pc-bios/s390-ccw/libc/string/memmove.c | 42 ++ pc-bios/s390-ccw/libc/string/memset.c | 25 + pc-bios/s390-ccw/libc/string/strcasecmp.c | 28 + pc-bios/s390-ccw/libc/string/strcat.c | 24 + pc-bios/s390-ccw/libc/string/strchr.c | 28 + pc-bios/s390-ccw/libc/string/strcmp.c | 28 + pc-bios/s390-ccw/libc/string/strcpy.c | 25 + pc-bios/s390-ccw/libc/string/strlen.c | 27 + pc-bios/s390-ccw/libc/string/strncasecmp.c | 32 + pc-bios/s390-ccw/libc/string/strncmp.c | 31 + pc-bios/s390-ccw/libc/string/strncpy.c | 33 + pc-bios/s390-ccw/libc/string/strstr.c | 37 ++ pc-bios/s390-ccw/libc/string/strtok.c | 45 ++ pc-bios/s390-ccw/libnet/Makefile | 42 ++ pc-bios/s390-ccw/libnet/args.c | 179 ++++++ pc-bios/s390-ccw/libnet/args.h | 23 + pc-bios/s390-ccw/libnet/dhcp.c | 955 +++++++++++++++++++++++++++++ pc-bios/s390-ccw/libnet/dhcp.h | 49 ++ pc-bios/s390-ccw/libnet/dhcpv6.c | 212 +++++++ pc-bios/s390-ccw/libnet/dhcpv6.h | 154 +++++ pc-bios/s390-ccw/libnet/dns.c | 526 ++++++++++++++++ pc-bios/s390-ccw/libnet/dns.h | 28 + pc-bios/s390-ccw/libnet/ethernet.c | 189 ++++++ pc-bios/s390-ccw/libnet/ethernet.h | 47 ++ pc-bios/s390-ccw/libnet/icmpv6.c | 409 ++++++++++++ pc-bios/s390-ccw/libnet/icmpv6.h | 135 ++++ pc-bios/s390-ccw/libnet/ipv4.c | 898 +++++++++++++++++++++++++++ pc-bios/s390-ccw/libnet/ipv4.h | 97 +++ pc-bios/s390-ccw/libnet/ipv6.c | 774 +++++++++++++++++++++++ pc-bios/s390-ccw/libnet/ipv6.h | 188 ++++++ pc-bios/s390-ccw/libnet/ndp.c | 184 ++++++ pc-bios/s390-ccw/libnet/ndp.h | 72 +++ pc-bios/s390-ccw/libnet/netapps.h | 25 + pc-bios/s390-ccw/libnet/netload.c | 600 ++++++++++++++++++ pc-bios/s390-ccw/libnet/tcp.c | 46 ++ pc-bios/s390-ccw/libnet/tcp.h | 27 + pc-bios/s390-ccw/libnet/tftp.c | 595 ++++++++++++++++++ pc-bios/s390-ccw/libnet/tftp.h | 50 ++ pc-bios/s390-ccw/libnet/time.h | 6 + pc-bios/s390-ccw/libnet/timer.c | 40 ++ pc-bios/s390-ccw/libnet/udp.c | 115 ++++ pc-bios/s390-ccw/libnet/udp.h | 53 ++ pc-bios/s390-ccw/main.c | 3 +- pc-bios/s390-ccw/s390-ccw.h | 30 +- pc-bios/s390-ccw/sbrk.c | 39 ++ pc-bios/s390-ccw/sclp.c | 32 +- pc-bios/s390-ccw/virtio-net.c | 125 ++++ pc-bios/s390-ccw/virtio.c | 16 +- pc-bios/s390-ccw/virtio.h | 11 + 104 files changed, 9296 insertions(+), 57 deletions(-) create mode 100644 pc-bios/s390-ccw/libc/Makefile create mode 100644 pc-bios/s390-ccw/libc/README.txt create mode 100644 pc-bios/s390-ccw/libc/ctype/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/ctype/isdigit.c create mode 100644 pc-bios/s390-ccw/libc/ctype/isprint.c create mode 100644 pc-bios/s390-ccw/libc/ctype/isspace.c create mode 100644 pc-bios/s390-ccw/libc/ctype/isxdigit.c create mode 100644 pc-bios/s390-ccw/libc/ctype/tolower.c create mode 100644 pc-bios/s390-ccw/libc/ctype/toupper.c create mode 100644 pc-bios/s390-ccw/libc/include/ctype.h create mode 100644 pc-bios/s390-ccw/libc/include/errno.h create mode 100644 pc-bios/s390-ccw/libc/include/limits.h create mode 100644 pc-bios/s390-ccw/libc/include/stdarg.h create mode 100644 pc-bios/s390-ccw/libc/include/stdbool.h create mode 100644 pc-bios/s390-ccw/libc/include/stddef.h create mode 100644 pc-bios/s390-ccw/libc/include/stdint.h create mode 100644 pc-bios/s390-ccw/libc/include/stdio.h create mode 100644 pc-bios/s390-ccw/libc/include/stdlib.h create mode 100644 pc-bios/s390-ccw/libc/include/string.h create mode 100644 pc-bios/s390-ccw/libc/include/sys/socket.h create mode 100644 pc-bios/s390-ccw/libc/include/unistd.h create mode 100644 pc-bios/s390-ccw/libc/stdio/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/stdio/fileno.c create mode 100644 pc-bios/s390-ccw/libc/stdio/fprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/printf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/putc.c create mode 100644 pc-bios/s390-ccw/libc/stdio/putchar.c create mode 100644 pc-bios/s390-ccw/libc/stdio/puts.c create mode 100644 pc-bios/s390-ccw/libc/stdio/setvbuf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/sprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/stdchnls.c create mode 100644 pc-bios/s390-ccw/libc/stdio/vfprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/vsnprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/vsprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/stdlib/atoi.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/atol.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/error.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/free.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/malloc.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/malloc_defs.h create mode 100644 pc-bios/s390-ccw/libc/stdlib/memalign.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/rand.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/realloc.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/strtol.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/strtoul.c create mode 100644 pc-bios/s390-ccw/libc/string/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/string/memchr.c create mode 100644 pc-bios/s390-ccw/libc/string/memcmp.c create mode 100644 pc-bios/s390-ccw/libc/string/memcpy.c create mode 100644 pc-bios/s390-ccw/libc/string/memmove.c create mode 100644 pc-bios/s390-ccw/libc/string/memset.c create mode 100644 pc-bios/s390-ccw/libc/string/strcasecmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strcat.c create mode 100644 pc-bios/s390-ccw/libc/string/strchr.c create mode 100644 pc-bios/s390-ccw/libc/string/strcmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strcpy.c create mode 100644 pc-bios/s390-ccw/libc/string/strlen.c create mode 100644 pc-bios/s390-ccw/libc/string/strncasecmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strncmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strncpy.c create mode 100644 pc-bios/s390-ccw/libc/string/strstr.c create mode 100644 pc-bios/s390-ccw/libc/string/strtok.c create mode 100644 pc-bios/s390-ccw/libnet/Makefile create mode 100644 pc-bios/s390-ccw/libnet/args.c create mode 100644 pc-bios/s390-ccw/libnet/args.h create mode 100644 pc-bios/s390-ccw/libnet/dhcp.c create mode 100644 pc-bios/s390-ccw/libnet/dhcp.h create mode 100644 pc-bios/s390-ccw/libnet/dhcpv6.c create mode 100644 pc-bios/s390-ccw/libnet/dhcpv6.h create mode 100644 pc-bios/s390-ccw/libnet/dns.c create mode 100644 pc-bios/s390-ccw/libnet/dns.h create mode 100644 pc-bios/s390-ccw/libnet/ethernet.c create mode 100644 pc-bios/s390-ccw/libnet/ethernet.h create mode 100644 pc-bios/s390-ccw/libnet/icmpv6.c create mode 100644 pc-bios/s390-ccw/libnet/icmpv6.h create mode 100644 pc-bios/s390-ccw/libnet/ipv4.c create mode 100644 pc-bios/s390-ccw/libnet/ipv4.h create mode 100644 pc-bios/s390-ccw/libnet/ipv6.c create mode 100644 pc-bios/s390-ccw/libnet/ipv6.h create mode 100644 pc-bios/s390-ccw/libnet/ndp.c create mode 100644 pc-bios/s390-ccw/libnet/ndp.h create mode 100644 pc-bios/s390-ccw/libnet/netapps.h create mode 100644 pc-bios/s390-ccw/libnet/netload.c create mode 100644 pc-bios/s390-ccw/libnet/tcp.c create mode 100644 pc-bios/s390-ccw/libnet/tcp.h create mode 100644 pc-bios/s390-ccw/libnet/tftp.c create mode 100644 pc-bios/s390-ccw/libnet/tftp.h create mode 100644 pc-bios/s390-ccw/libnet/time.h create mode 100644 pc-bios/s390-ccw/libnet/timer.c create mode 100644 pc-bios/s390-ccw/libnet/udp.c create mode 100644 pc-bios/s390-ccw/libnet/udp.h create mode 100644 pc-bios/s390-ccw/sbrk.c create mode 100644 pc-bios/s390-ccw/virtio-net.c
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? Thomas Thomas Huth (14): pc-bios/s390-ccw: Add the libc from the SLOF firmware pc-bios/s390-ccw: Start using the libc from SLOF pc-bios/s390-ccw: Add a write() function for stdio pc-bios/s390-ccw: Add implementation of sbrk() pc-bios/s390-ccw: Add the TFTP network loading stack from SLOF libnet: Remove remainders of netsave code libnet: Rework error message printing libnet: Refactor some code of netload() into a separate function pc-bios/s390-ccw: Make the basic libnet code compilable pc-bios/s390-ccw: Add timer code for the libnet pc-bios/s390-ccw: Add virtio-net driver code pc-bios/s390-ccw: Load file via an intermediate .INS file pc-bios/s390-ccw: Allow loading to address 0 pc-bios/s390-ccw: Wire up the netload code configure | 6 +- hw/s390x/ipl.c | 2 +- pc-bios/s390-ccw/Makefile | 14 +- pc-bios/s390-ccw/bootmap.c | 10 +- pc-bios/s390-ccw/bootmap.h | 1 + pc-bios/s390-ccw/libc/Makefile | 47 ++ pc-bios/s390-ccw/libc/README.txt | 49 ++ pc-bios/s390-ccw/libc/ctype/Makefile.inc | 21 + pc-bios/s390-ccw/libc/ctype/isdigit.c | 25 + pc-bios/s390-ccw/libc/ctype/isprint.c | 18 + pc-bios/s390-ccw/libc/ctype/isspace.c | 29 + pc-bios/s390-ccw/libc/ctype/isxdigit.c | 21 + pc-bios/s390-ccw/libc/ctype/tolower.c | 18 + pc-bios/s390-ccw/libc/ctype/toupper.c | 21 + pc-bios/s390-ccw/libc/include/ctype.h | 24 + pc-bios/s390-ccw/libc/include/errno.h | 34 + pc-bios/s390-ccw/libc/include/limits.h | 32 + pc-bios/s390-ccw/libc/include/stdarg.h | 22 + pc-bios/s390-ccw/libc/include/stdbool.h | 20 + pc-bios/s390-ccw/libc/include/stddef.h | 25 + pc-bios/s390-ccw/libc/include/stdint.h | 28 + pc-bios/s390-ccw/libc/include/stdio.h | 63 ++ pc-bios/s390-ccw/libc/include/stdlib.h | 34 + pc-bios/s390-ccw/libc/include/string.h | 37 ++ pc-bios/s390-ccw/libc/include/sys/socket.h | 53 ++ pc-bios/s390-ccw/libc/include/unistd.h | 28 + pc-bios/s390-ccw/libc/stdio/Makefile.inc | 24 + pc-bios/s390-ccw/libc/stdio/fileno.c | 19 + pc-bios/s390-ccw/libc/stdio/fprintf.c | 26 + pc-bios/s390-ccw/libc/stdio/printf.c | 27 + pc-bios/s390-ccw/libc/stdio/putc.c | 25 + pc-bios/s390-ccw/libc/stdio/putchar.c | 21 + pc-bios/s390-ccw/libc/stdio/puts.c | 28 + pc-bios/s390-ccw/libc/stdio/setvbuf.c | 28 + pc-bios/s390-ccw/libc/stdio/sprintf.c | 30 + pc-bios/s390-ccw/libc/stdio/stdchnls.c | 23 + pc-bios/s390-ccw/libc/stdio/vfprintf.c | 27 + pc-bios/s390-ccw/libc/stdio/vsnprintf.c | 298 +++++++++ pc-bios/s390-ccw/libc/stdio/vsprintf.c | 19 + pc-bios/s390-ccw/libc/stdlib/Makefile.inc | 23 + pc-bios/s390-ccw/libc/stdlib/atoi.c | 18 + pc-bios/s390-ccw/libc/stdlib/atol.c | 18 + pc-bios/s390-ccw/libc/stdlib/error.c | 15 + pc-bios/s390-ccw/libc/stdlib/free.c | 26 + pc-bios/s390-ccw/libc/stdlib/malloc.c | 157 +++++ pc-bios/s390-ccw/libc/stdlib/malloc_defs.h | 16 + pc-bios/s390-ccw/libc/stdlib/memalign.c | 26 + pc-bios/s390-ccw/libc/stdlib/rand.c | 29 + pc-bios/s390-ccw/libc/stdlib/realloc.c | 40 ++ pc-bios/s390-ccw/libc/stdlib/strtol.c | 115 ++++ pc-bios/s390-ccw/libc/stdlib/strtoul.c | 105 ++++ pc-bios/s390-ccw/libc/string/Makefile.inc | 23 + pc-bios/s390-ccw/libc/string/memchr.c | 29 + pc-bios/s390-ccw/libc/string/memcmp.c | 30 + pc-bios/s390-ccw/libc/string/memcpy.c | 27 + pc-bios/s390-ccw/libc/string/memmove.c | 42 ++ pc-bios/s390-ccw/libc/string/memset.c | 25 + pc-bios/s390-ccw/libc/string/strcasecmp.c | 28 + pc-bios/s390-ccw/libc/string/strcat.c | 24 + pc-bios/s390-ccw/libc/string/strchr.c | 28 + pc-bios/s390-ccw/libc/string/strcmp.c | 28 + pc-bios/s390-ccw/libc/string/strcpy.c | 25 + pc-bios/s390-ccw/libc/string/strlen.c | 27 + pc-bios/s390-ccw/libc/string/strncasecmp.c | 32 + pc-bios/s390-ccw/libc/string/strncmp.c | 31 + pc-bios/s390-ccw/libc/string/strncpy.c | 33 + pc-bios/s390-ccw/libc/string/strstr.c | 37 ++ pc-bios/s390-ccw/libc/string/strtok.c | 45 ++ pc-bios/s390-ccw/libnet/Makefile | 42 ++ pc-bios/s390-ccw/libnet/args.c | 179 ++++++ pc-bios/s390-ccw/libnet/args.h | 23 + pc-bios/s390-ccw/libnet/dhcp.c | 955 +++++++++++++++++++++++++++++ pc-bios/s390-ccw/libnet/dhcp.h | 49 ++ pc-bios/s390-ccw/libnet/dhcpv6.c | 212 +++++++ pc-bios/s390-ccw/libnet/dhcpv6.h | 154 +++++ pc-bios/s390-ccw/libnet/dns.c | 526 ++++++++++++++++ pc-bios/s390-ccw/libnet/dns.h | 28 + pc-bios/s390-ccw/libnet/ethernet.c | 189 ++++++ pc-bios/s390-ccw/libnet/ethernet.h | 47 ++ pc-bios/s390-ccw/libnet/icmpv6.c | 409 ++++++++++++ pc-bios/s390-ccw/libnet/icmpv6.h | 135 ++++ pc-bios/s390-ccw/libnet/ipv4.c | 898 +++++++++++++++++++++++++++ pc-bios/s390-ccw/libnet/ipv4.h | 97 +++ pc-bios/s390-ccw/libnet/ipv6.c | 774 +++++++++++++++++++++++ pc-bios/s390-ccw/libnet/ipv6.h | 188 ++++++ pc-bios/s390-ccw/libnet/ndp.c | 184 ++++++ pc-bios/s390-ccw/libnet/ndp.h | 72 +++ pc-bios/s390-ccw/libnet/netapps.h | 25 + pc-bios/s390-ccw/libnet/netload.c | 600 ++++++++++++++++++ pc-bios/s390-ccw/libnet/tcp.c | 46 ++ pc-bios/s390-ccw/libnet/tcp.h | 27 + pc-bios/s390-ccw/libnet/tftp.c | 595 ++++++++++++++++++ pc-bios/s390-ccw/libnet/tftp.h | 50 ++ pc-bios/s390-ccw/libnet/time.h | 6 + pc-bios/s390-ccw/libnet/timer.c | 40 ++ pc-bios/s390-ccw/libnet/udp.c | 115 ++++ pc-bios/s390-ccw/libnet/udp.h | 53 ++ pc-bios/s390-ccw/main.c | 3 +- pc-bios/s390-ccw/s390-ccw.h | 30 +- pc-bios/s390-ccw/sbrk.c | 39 ++ pc-bios/s390-ccw/sclp.c | 32 +- pc-bios/s390-ccw/virtio-net.c | 125 ++++ pc-bios/s390-ccw/virtio.c | 16 +- pc-bios/s390-ccw/virtio.h | 11 + 104 files changed, 9296 insertions(+), 57 deletions(-) create mode 100644 pc-bios/s390-ccw/libc/Makefile create mode 100644 pc-bios/s390-ccw/libc/README.txt create mode 100644 pc-bios/s390-ccw/libc/ctype/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/ctype/isdigit.c create mode 100644 pc-bios/s390-ccw/libc/ctype/isprint.c create mode 100644 pc-bios/s390-ccw/libc/ctype/isspace.c create mode 100644 pc-bios/s390-ccw/libc/ctype/isxdigit.c create mode 100644 pc-bios/s390-ccw/libc/ctype/tolower.c create mode 100644 pc-bios/s390-ccw/libc/ctype/toupper.c create mode 100644 pc-bios/s390-ccw/libc/include/ctype.h create mode 100644 pc-bios/s390-ccw/libc/include/errno.h create mode 100644 pc-bios/s390-ccw/libc/include/limits.h create mode 100644 pc-bios/s390-ccw/libc/include/stdarg.h create mode 100644 pc-bios/s390-ccw/libc/include/stdbool.h create mode 100644 pc-bios/s390-ccw/libc/include/stddef.h create mode 100644 pc-bios/s390-ccw/libc/include/stdint.h create mode 100644 pc-bios/s390-ccw/libc/include/stdio.h create mode 100644 pc-bios/s390-ccw/libc/include/stdlib.h create mode 100644 pc-bios/s390-ccw/libc/include/string.h create mode 100644 pc-bios/s390-ccw/libc/include/sys/socket.h create mode 100644 pc-bios/s390-ccw/libc/include/unistd.h create mode 100644 pc-bios/s390-ccw/libc/stdio/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/stdio/fileno.c create mode 100644 pc-bios/s390-ccw/libc/stdio/fprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/printf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/putc.c create mode 100644 pc-bios/s390-ccw/libc/stdio/putchar.c create mode 100644 pc-bios/s390-ccw/libc/stdio/puts.c create mode 100644 pc-bios/s390-ccw/libc/stdio/setvbuf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/sprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/stdchnls.c create mode 100644 pc-bios/s390-ccw/libc/stdio/vfprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/vsnprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdio/vsprintf.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/stdlib/atoi.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/atol.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/error.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/free.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/malloc.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/malloc_defs.h create mode 100644 pc-bios/s390-ccw/libc/stdlib/memalign.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/rand.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/realloc.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/strtol.c create mode 100644 pc-bios/s390-ccw/libc/stdlib/strtoul.c create mode 100644 pc-bios/s390-ccw/libc/string/Makefile.inc create mode 100644 pc-bios/s390-ccw/libc/string/memchr.c create mode 100644 pc-bios/s390-ccw/libc/string/memcmp.c create mode 100644 pc-bios/s390-ccw/libc/string/memcpy.c create mode 100644 pc-bios/s390-ccw/libc/string/memmove.c create mode 100644 pc-bios/s390-ccw/libc/string/memset.c create mode 100644 pc-bios/s390-ccw/libc/string/strcasecmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strcat.c create mode 100644 pc-bios/s390-ccw/libc/string/strchr.c create mode 100644 pc-bios/s390-ccw/libc/string/strcmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strcpy.c create mode 100644 pc-bios/s390-ccw/libc/string/strlen.c create mode 100644 pc-bios/s390-ccw/libc/string/strncasecmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strncmp.c create mode 100644 pc-bios/s390-ccw/libc/string/strncpy.c create mode 100644 pc-bios/s390-ccw/libc/string/strstr.c create mode 100644 pc-bios/s390-ccw/libc/string/strtok.c create mode 100644 pc-bios/s390-ccw/libnet/Makefile create mode 100644 pc-bios/s390-ccw/libnet/args.c create mode 100644 pc-bios/s390-ccw/libnet/args.h create mode 100644 pc-bios/s390-ccw/libnet/dhcp.c create mode 100644 pc-bios/s390-ccw/libnet/dhcp.h create mode 100644 pc-bios/s390-ccw/libnet/dhcpv6.c create mode 100644 pc-bios/s390-ccw/libnet/dhcpv6.h create mode 100644 pc-bios/s390-ccw/libnet/dns.c create mode 100644 pc-bios/s390-ccw/libnet/dns.h create mode 100644 pc-bios/s390-ccw/libnet/ethernet.c create mode 100644 pc-bios/s390-ccw/libnet/ethernet.h create mode 100644 pc-bios/s390-ccw/libnet/icmpv6.c create mode 100644 pc-bios/s390-ccw/libnet/icmpv6.h create mode 100644 pc-bios/s390-ccw/libnet/ipv4.c create mode 100644 pc-bios/s390-ccw/libnet/ipv4.h create mode 100644 pc-bios/s390-ccw/libnet/ipv6.c create mode 100644 pc-bios/s390-ccw/libnet/ipv6.h create mode 100644 pc-bios/s390-ccw/libnet/ndp.c create mode 100644 pc-bios/s390-ccw/libnet/ndp.h create mode 100644 pc-bios/s390-ccw/libnet/netapps.h create mode 100644 pc-bios/s390-ccw/libnet/netload.c create mode 100644 pc-bios/s390-ccw/libnet/tcp.c create mode 100644 pc-bios/s390-ccw/libnet/tcp.h create mode 100644 pc-bios/s390-ccw/libnet/tftp.c create mode 100644 pc-bios/s390-ccw/libnet/tftp.h create mode 100644 pc-bios/s390-ccw/libnet/time.h create mode 100644 pc-bios/s390-ccw/libnet/timer.c create mode 100644 pc-bios/s390-ccw/libnet/udp.c create mode 100644 pc-bios/s390-ccw/libnet/udp.h create mode 100644 pc-bios/s390-ccw/sbrk.c create mode 100644 pc-bios/s390-ccw/virtio-net.c -- 1.8.3.1
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
Interesting work, thanks for giving it a ry. On 06/27/2017 01:48 PM, 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. What is the licensing situation with SLOF? > > 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? Yes, sure. I think up to 1M everything is fine as long as the startup time stays low (e.g. if we want to do something like clear containers. Right now I can start a small Linux guest from qemu start to command line in <100ms without any optimization) > > - 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. ...)? I agree with Viktor that supporting a pxelinux config file is probably the better way, since this is what all exisiting servers admins understand. For the time being Linux will be the most relevant guest and requiring changes in management infrastructure will certainly make things very hard. > - 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? Is it possible to enhance SLOF and then link to the existing SLOF code? > > - 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?
On 28.06.2017 09:43, Christian Borntraeger wrote: > Interesting work, thanks for giving it a ry. > > On 06/27/2017 01:48 PM, 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. > > What is the licensing situation with SLOF? All its code is licensed under the 3-Clause BSD License: https://github.com/aik/SLOF/blob/master/LICENSE AFAIK it should be fine to use such code in GPL-ed sources like the s390-ccw firmware, shouldn't it? >> - 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. ...)? > > I agree with Viktor that supporting a pxelinux config file is probably the > better way, since this is what all exisiting servers admins understand. For > the time being Linux will be the most relevant guest and requiring changes in > management infrastructure will certainly make things very hard. I have to say, the more I read about pxelinux, the more I think we should *not* directly support this in the firmware. pxelinux is clearly a secondary stage bootloader, with a rather complex config file, and features like config file name guessing via MAC-address or IP-address ... if we really want to support that on s390x, too, I think it should stay in a external binary instead, and not directly incorporated into the s390-ccw firmware (so that users finally have the choice whether they want to use pxelinux-style config files or grub2 or something different one day). I guess the .INS file parsing in firmware was already a bad idea... all other typical firmware implementations can also only load one file - and if you need to load multiple files, you've got to use a secondary stage bootloader like pxelinux, yaboot or grub2. So if we agree to add network booting directly into the s390-ccw firmware, I think we should do the same here and only support loading of one file (without an additional config file). But then the question is, of course, whether it makes sense to add that support to the firmware at all, or whether we should simply continue with the current "s390-netboot.img" secondary-loader approach... >> - 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? > > Is it possible to enhance SLOF and then link to the existing SLOF code? I already submitted some of the clean-up patches to the SLOF mailing list, and Alexey has merged them now, e.g.: https://github.com/aik/SLOF/commit/140c3f39db4ce4c0 And as I already mentioned in my reply to David, it should theoretically be possible to use the code from the roms/SLOF submodule in QEMU ... but then we've got to deal with sudden changes in the SLOF repository which might cause unwanted problems in the s390-ccw firmware. I guess we could give it a try (the libc code is very, very stable in SLOF, and the libnet code also changes only very seldomly) - of course only if we really decide that we want to have TFTP support directly in the firmware. If we rather want to continue with the s390-netboot.img approach instead, I have got to reconsider whether I continue with my efforts by putting that stuff into an external binary, or whether it makes more sense to look into porting pxelinux, grub2 or petitboot instead... Thomas
On 28.06.2017 10:59, Thomas Huth wrote: > On 28.06.2017 09:43, Christian Borntraeger wrote: >> Interesting work, thanks for giving it a ry. >> >> On 06/27/2017 01:48 PM, 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. >> >> What is the licensing situation with SLOF? > > All its code is licensed under the 3-Clause BSD License: > > https://github.com/aik/SLOF/blob/master/LICENSE > > AFAIK it should be fine to use such code in GPL-ed sources like the > s390-ccw firmware, shouldn't it? > >>> - 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. ...)? >> >> I agree with Viktor that supporting a pxelinux config file is probably the >> better way, since this is what all exisiting servers admins understand. For >> the time being Linux will be the most relevant guest and requiring changes in >> management infrastructure will certainly make things very hard. > > I have to say, the more I read about pxelinux, the more I think we > should *not* directly support this in the firmware. pxelinux is clearly > a secondary stage bootloader, with a rather complex config file, and > features like config file name guessing via MAC-address or IP-address > ... if we really want to support that on s390x, too, I think it should > stay in a external binary instead, and not directly incorporated into > the s390-ccw firmware (so that users finally have the choice whether > they want to use pxelinux-style config files or grub2 or something > different one day). > > I guess the .INS file parsing in firmware was already a bad idea... all > other typical firmware implementations can also only load one file - and > if you need to load multiple files, you've got to use a secondary stage > bootloader like pxelinux, yaboot or grub2. So if we agree to add network > booting directly into the s390-ccw firmware, I think we should do the > same here and only support loading of one file (without an additional > config file). But then the question is, of course, whether it makes > sense to add that support to the firmware at all, or whether we should > simply continue with the current "s390-netboot.img" secondary-loader > approach... > >>> - 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? >> >> Is it possible to enhance SLOF and then link to the existing SLOF code? > > I already submitted some of the clean-up patches to the SLOF mailing > list, and Alexey has merged them now, e.g.: > > https://github.com/aik/SLOF/commit/140c3f39db4ce4c0 > > And as I already mentioned in my reply to David, it should theoretically > be possible to use the code from the roms/SLOF submodule in QEMU ... > but then we've got to deal with sudden changes in the SLOF repository > which might cause unwanted problems in the s390-ccw firmware. I guess we > could give it a try (the libc code is very, very stable in SLOF, and the > libnet code also changes only very seldomly) - of course only if we > really decide that we want to have TFTP support directly in the > firmware. If we rather want to continue with the s390-netboot.img > approach instead, I have got to reconsider whether I continue with my > efforts by putting that stuff into an external binary, or whether it > makes more sense to look into porting pxelinux, grub2 or petitboot > instead... OK, thinking about all of this again, what do you think of the following approach: Let's do not include network booting code into the s390-ccw.img, but keep the way that it uses an external s390-netboot.img for this job. I'll then try to add an additional s390-netboot.img target to the Makefile, which will only be built if the roms/SLOF submodule has been checked out. That target then uses the libc and libnet from the SLOF submodule and links it with my virtio-net driver and some other required code from the s390-ccw bios into a s390-netboot.img binary that can be used for network booting. This way ... - the main s390-ccw.img stays independent from the changes in the SLOF, and we can tackle possible problems in the s390-netboot.img independently. And we don't have to deal with coding style issues in the libc and libnet. - we can ship a s390-netboot.img with QEMU directly, so that network booting is possible out of the box without forcing the users / downstream distros to figure out how to build a netboot.img on their own - we keep the possibility to use alternative s390-netboot.imgs in case the users need advanced features like booting via HTTP Does that sound like an acceptable strategy? Thomas
On 06/29/2017 10:17 AM, Thomas Huth wrote: > On 28.06.2017 10:59, Thomas Huth wrote: >> On 28.06.2017 09:43, Christian Borntraeger wrote: >>> Interesting work, thanks for giving it a ry. >>> >>> On 06/27/2017 01:48 PM, 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. >>> >>> What is the licensing situation with SLOF? >> >> All its code is licensed under the 3-Clause BSD License: >> >> https://github.com/aik/SLOF/blob/master/LICENSE >> >> AFAIK it should be fine to use such code in GPL-ed sources like the >> s390-ccw firmware, shouldn't it? >> >>>> - 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. ...)? >>> >>> I agree with Viktor that supporting a pxelinux config file is probably the >>> better way, since this is what all exisiting servers admins understand. For >>> the time being Linux will be the most relevant guest and requiring changes in >>> management infrastructure will certainly make things very hard. >> >> I have to say, the more I read about pxelinux, the more I think we >> should *not* directly support this in the firmware. pxelinux is clearly >> a secondary stage bootloader, with a rather complex config file, and >> features like config file name guessing via MAC-address or IP-address >> ... if we really want to support that on s390x, too, I think it should >> stay in a external binary instead, and not directly incorporated into >> the s390-ccw firmware (so that users finally have the choice whether >> they want to use pxelinux-style config files or grub2 or something >> different one day). >> >> I guess the .INS file parsing in firmware was already a bad idea... all >> other typical firmware implementations can also only load one file - and >> if you need to load multiple files, you've got to use a secondary stage >> bootloader like pxelinux, yaboot or grub2. So if we agree to add network >> booting directly into the s390-ccw firmware, I think we should do the >> same here and only support loading of one file (without an additional >> config file). But then the question is, of course, whether it makes >> sense to add that support to the firmware at all, or whether we should >> simply continue with the current "s390-netboot.img" secondary-loader >> approach... >> >>>> - 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? >>> >>> Is it possible to enhance SLOF and then link to the existing SLOF code? >> >> I already submitted some of the clean-up patches to the SLOF mailing >> list, and Alexey has merged them now, e.g.: >> >> https://github.com/aik/SLOF/commit/140c3f39db4ce4c0 >> >> And as I already mentioned in my reply to David, it should theoretically >> be possible to use the code from the roms/SLOF submodule in QEMU ... >> but then we've got to deal with sudden changes in the SLOF repository >> which might cause unwanted problems in the s390-ccw firmware. I guess we >> could give it a try (the libc code is very, very stable in SLOF, and the >> libnet code also changes only very seldomly) - of course only if we >> really decide that we want to have TFTP support directly in the >> firmware. If we rather want to continue with the s390-netboot.img >> approach instead, I have got to reconsider whether I continue with my >> efforts by putting that stuff into an external binary, or whether it >> makes more sense to look into porting pxelinux, grub2 or petitboot >> instead... > > OK, thinking about all of this again, what do you think of the following > approach: > > Let's do not include network booting code into the s390-ccw.img, but > keep the way that it uses an external s390-netboot.img for this job. > > I'll then try to add an additional s390-netboot.img target to the > Makefile, which will only be built if the roms/SLOF submodule has been > checked out. That target then uses the libc and libnet from the SLOF > submodule and links it with my virtio-net driver and some other required > code from the s390-ccw bios into a s390-netboot.img binary that can be > used for network booting. > > This way ... > - the main s390-ccw.img stays independent from the changes in the SLOF, > and we can tackle possible problems in the s390-netboot.img > independently. And we don't have to deal with coding style issues in the > libc and libnet. > - we can ship a s390-netboot.img with QEMU directly, so that network > booting is possible out of the box without forcing the users / > downstream distros to figure out how to build a netboot.img on their own > - we keep the possibility to use alternative s390-netboot.imgs in case > the users need advanced features like booting via HTTP > > Does that sound like an acceptable strategy? Sounds perfectly fine to me. Thanks a lot for doing this.
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
On 27.06.2017 23:15, Alexander Graf wrote: > > On 27.06.17 13:48, Thomas Huth wrote: [...] >> - 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. I can't speak of U-Boot, but you certainly don't want to port edk2 to a big endian machine. Been there, seen that. > 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. petitboot is basically a Linux system (with a shell, too). And grub2 is also a common boot loader on x86 nowadays ... so not sure whether they would really be a knowledge sharing nightmare? I think they would be more common for "server" people than the U-Boot loader, which is likely only familiar to "embedded" folks. Thomas
Hi, > > 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. > > I can't speak of U-Boot, but you certainly don't want to port edk2 to > a big endian machine. Been there, seen that. > would really be a knowledge sharing nightmare? I think they would be > more common for "server" people than the U-Boot loader, which is > likely > only familiar to "embedded" folks. Well, u-boot supports some[1] EFI interfaces these days, so you can run standard efi grub2 on embedded arm boards. From that point of view porting uboot to s390 might not be as silly as it initially looks like. cheers, Gerd [1] barely enough to make grub2 happy.
Hi Thomas, This is really interesting :) On 06/27/2017 07:48 AM, 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? IMHO 75k is not that huge compared to the Linux based netboot image. > > - 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? Can't it be extended to support HTTP boot? > > Thomas > > > Thomas Huth (14): > pc-bios/s390-ccw: Add the libc from the SLOF firmware > pc-bios/s390-ccw: Start using the libc from SLOF > pc-bios/s390-ccw: Add a write() function for stdio > pc-bios/s390-ccw: Add implementation of sbrk() > pc-bios/s390-ccw: Add the TFTP network loading stack from SLOF > libnet: Remove remainders of netsave code > libnet: Rework error message printing > libnet: Refactor some code of netload() into a separate function > pc-bios/s390-ccw: Make the basic libnet code compilable > pc-bios/s390-ccw: Add timer code for the libnet > pc-bios/s390-ccw: Add virtio-net driver code > pc-bios/s390-ccw: Load file via an intermediate .INS file > pc-bios/s390-ccw: Allow loading to address 0 > pc-bios/s390-ccw: Wire up the netload code > > configure | 6 +- > hw/s390x/ipl.c | 2 +- > pc-bios/s390-ccw/Makefile | 14 +- > pc-bios/s390-ccw/bootmap.c | 10 +- > pc-bios/s390-ccw/bootmap.h | 1 + > pc-bios/s390-ccw/libc/Makefile | 47 ++ > pc-bios/s390-ccw/libc/README.txt | 49 ++ > pc-bios/s390-ccw/libc/ctype/Makefile.inc | 21 + > pc-bios/s390-ccw/libc/ctype/isdigit.c | 25 + > pc-bios/s390-ccw/libc/ctype/isprint.c | 18 + > pc-bios/s390-ccw/libc/ctype/isspace.c | 29 + > pc-bios/s390-ccw/libc/ctype/isxdigit.c | 21 + > pc-bios/s390-ccw/libc/ctype/tolower.c | 18 + > pc-bios/s390-ccw/libc/ctype/toupper.c | 21 + > pc-bios/s390-ccw/libc/include/ctype.h | 24 + > pc-bios/s390-ccw/libc/include/errno.h | 34 + > pc-bios/s390-ccw/libc/include/limits.h | 32 + > pc-bios/s390-ccw/libc/include/stdarg.h | 22 + > pc-bios/s390-ccw/libc/include/stdbool.h | 20 + > pc-bios/s390-ccw/libc/include/stddef.h | 25 + > pc-bios/s390-ccw/libc/include/stdint.h | 28 + > pc-bios/s390-ccw/libc/include/stdio.h | 63 ++ > pc-bios/s390-ccw/libc/include/stdlib.h | 34 + > pc-bios/s390-ccw/libc/include/string.h | 37 ++ > pc-bios/s390-ccw/libc/include/sys/socket.h | 53 ++ > pc-bios/s390-ccw/libc/include/unistd.h | 28 + > pc-bios/s390-ccw/libc/stdio/Makefile.inc | 24 + > pc-bios/s390-ccw/libc/stdio/fileno.c | 19 + > pc-bios/s390-ccw/libc/stdio/fprintf.c | 26 + > pc-bios/s390-ccw/libc/stdio/printf.c | 27 + > pc-bios/s390-ccw/libc/stdio/putc.c | 25 + > pc-bios/s390-ccw/libc/stdio/putchar.c | 21 + > pc-bios/s390-ccw/libc/stdio/puts.c | 28 + > pc-bios/s390-ccw/libc/stdio/setvbuf.c | 28 + > pc-bios/s390-ccw/libc/stdio/sprintf.c | 30 + > pc-bios/s390-ccw/libc/stdio/stdchnls.c | 23 + > pc-bios/s390-ccw/libc/stdio/vfprintf.c | 27 + > pc-bios/s390-ccw/libc/stdio/vsnprintf.c | 298 +++++++++ > pc-bios/s390-ccw/libc/stdio/vsprintf.c | 19 + > pc-bios/s390-ccw/libc/stdlib/Makefile.inc | 23 + > pc-bios/s390-ccw/libc/stdlib/atoi.c | 18 + > pc-bios/s390-ccw/libc/stdlib/atol.c | 18 + > pc-bios/s390-ccw/libc/stdlib/error.c | 15 + > pc-bios/s390-ccw/libc/stdlib/free.c | 26 + > pc-bios/s390-ccw/libc/stdlib/malloc.c | 157 +++++ > pc-bios/s390-ccw/libc/stdlib/malloc_defs.h | 16 + > pc-bios/s390-ccw/libc/stdlib/memalign.c | 26 + > pc-bios/s390-ccw/libc/stdlib/rand.c | 29 + > pc-bios/s390-ccw/libc/stdlib/realloc.c | 40 ++ > pc-bios/s390-ccw/libc/stdlib/strtol.c | 115 ++++ > pc-bios/s390-ccw/libc/stdlib/strtoul.c | 105 ++++ > pc-bios/s390-ccw/libc/string/Makefile.inc | 23 + > pc-bios/s390-ccw/libc/string/memchr.c | 29 + > pc-bios/s390-ccw/libc/string/memcmp.c | 30 + > pc-bios/s390-ccw/libc/string/memcpy.c | 27 + > pc-bios/s390-ccw/libc/string/memmove.c | 42 ++ > pc-bios/s390-ccw/libc/string/memset.c | 25 + > pc-bios/s390-ccw/libc/string/strcasecmp.c | 28 + > pc-bios/s390-ccw/libc/string/strcat.c | 24 + > pc-bios/s390-ccw/libc/string/strchr.c | 28 + > pc-bios/s390-ccw/libc/string/strcmp.c | 28 + > pc-bios/s390-ccw/libc/string/strcpy.c | 25 + > pc-bios/s390-ccw/libc/string/strlen.c | 27 + > pc-bios/s390-ccw/libc/string/strncasecmp.c | 32 + > pc-bios/s390-ccw/libc/string/strncmp.c | 31 + > pc-bios/s390-ccw/libc/string/strncpy.c | 33 + > pc-bios/s390-ccw/libc/string/strstr.c | 37 ++ > pc-bios/s390-ccw/libc/string/strtok.c | 45 ++ > pc-bios/s390-ccw/libnet/Makefile | 42 ++ > pc-bios/s390-ccw/libnet/args.c | 179 ++++++ > pc-bios/s390-ccw/libnet/args.h | 23 + > pc-bios/s390-ccw/libnet/dhcp.c | 955 +++++++++++++++++++++++++++++ > pc-bios/s390-ccw/libnet/dhcp.h | 49 ++ > pc-bios/s390-ccw/libnet/dhcpv6.c | 212 +++++++ > pc-bios/s390-ccw/libnet/dhcpv6.h | 154 +++++ > pc-bios/s390-ccw/libnet/dns.c | 526 ++++++++++++++++ > pc-bios/s390-ccw/libnet/dns.h | 28 + > pc-bios/s390-ccw/libnet/ethernet.c | 189 ++++++ > pc-bios/s390-ccw/libnet/ethernet.h | 47 ++ > pc-bios/s390-ccw/libnet/icmpv6.c | 409 ++++++++++++ > pc-bios/s390-ccw/libnet/icmpv6.h | 135 ++++ > pc-bios/s390-ccw/libnet/ipv4.c | 898 +++++++++++++++++++++++++++ > pc-bios/s390-ccw/libnet/ipv4.h | 97 +++ > pc-bios/s390-ccw/libnet/ipv6.c | 774 +++++++++++++++++++++++ > pc-bios/s390-ccw/libnet/ipv6.h | 188 ++++++ > pc-bios/s390-ccw/libnet/ndp.c | 184 ++++++ > pc-bios/s390-ccw/libnet/ndp.h | 72 +++ > pc-bios/s390-ccw/libnet/netapps.h | 25 + > pc-bios/s390-ccw/libnet/netload.c | 600 ++++++++++++++++++ > pc-bios/s390-ccw/libnet/tcp.c | 46 ++ > pc-bios/s390-ccw/libnet/tcp.h | 27 + > pc-bios/s390-ccw/libnet/tftp.c | 595 ++++++++++++++++++ > pc-bios/s390-ccw/libnet/tftp.h | 50 ++ > pc-bios/s390-ccw/libnet/time.h | 6 + > pc-bios/s390-ccw/libnet/timer.c | 40 ++ > pc-bios/s390-ccw/libnet/udp.c | 115 ++++ > pc-bios/s390-ccw/libnet/udp.h | 53 ++ > pc-bios/s390-ccw/main.c | 3 +- > pc-bios/s390-ccw/s390-ccw.h | 30 +- > pc-bios/s390-ccw/sbrk.c | 39 ++ > pc-bios/s390-ccw/sclp.c | 32 +- > pc-bios/s390-ccw/virtio-net.c | 125 ++++ > pc-bios/s390-ccw/virtio.c | 16 +- > pc-bios/s390-ccw/virtio.h | 11 + > 104 files changed, 9296 insertions(+), 57 deletions(-) > create mode 100644 pc-bios/s390-ccw/libc/Makefile > create mode 100644 pc-bios/s390-ccw/libc/README.txt > create mode 100644 pc-bios/s390-ccw/libc/ctype/Makefile.inc > create mode 100644 pc-bios/s390-ccw/libc/ctype/isdigit.c > create mode 100644 pc-bios/s390-ccw/libc/ctype/isprint.c > create mode 100644 pc-bios/s390-ccw/libc/ctype/isspace.c > create mode 100644 pc-bios/s390-ccw/libc/ctype/isxdigit.c > create mode 100644 pc-bios/s390-ccw/libc/ctype/tolower.c > create mode 100644 pc-bios/s390-ccw/libc/ctype/toupper.c > create mode 100644 pc-bios/s390-ccw/libc/include/ctype.h > create mode 100644 pc-bios/s390-ccw/libc/include/errno.h > create mode 100644 pc-bios/s390-ccw/libc/include/limits.h > create mode 100644 pc-bios/s390-ccw/libc/include/stdarg.h > create mode 100644 pc-bios/s390-ccw/libc/include/stdbool.h > create mode 100644 pc-bios/s390-ccw/libc/include/stddef.h > create mode 100644 pc-bios/s390-ccw/libc/include/stdint.h > create mode 100644 pc-bios/s390-ccw/libc/include/stdio.h > create mode 100644 pc-bios/s390-ccw/libc/include/stdlib.h > create mode 100644 pc-bios/s390-ccw/libc/include/string.h > create mode 100644 pc-bios/s390-ccw/libc/include/sys/socket.h > create mode 100644 pc-bios/s390-ccw/libc/include/unistd.h > create mode 100644 pc-bios/s390-ccw/libc/stdio/Makefile.inc > create mode 100644 pc-bios/s390-ccw/libc/stdio/fileno.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/fprintf.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/printf.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/putc.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/putchar.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/puts.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/setvbuf.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/sprintf.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/stdchnls.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/vfprintf.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/vsnprintf.c > create mode 100644 pc-bios/s390-ccw/libc/stdio/vsprintf.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/Makefile.inc > create mode 100644 pc-bios/s390-ccw/libc/stdlib/atoi.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/atol.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/error.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/free.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/malloc.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/malloc_defs.h > create mode 100644 pc-bios/s390-ccw/libc/stdlib/memalign.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/rand.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/realloc.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/strtol.c > create mode 100644 pc-bios/s390-ccw/libc/stdlib/strtoul.c > create mode 100644 pc-bios/s390-ccw/libc/string/Makefile.inc > create mode 100644 pc-bios/s390-ccw/libc/string/memchr.c > create mode 100644 pc-bios/s390-ccw/libc/string/memcmp.c > create mode 100644 pc-bios/s390-ccw/libc/string/memcpy.c > create mode 100644 pc-bios/s390-ccw/libc/string/memmove.c > create mode 100644 pc-bios/s390-ccw/libc/string/memset.c > create mode 100644 pc-bios/s390-ccw/libc/string/strcasecmp.c > create mode 100644 pc-bios/s390-ccw/libc/string/strcat.c > create mode 100644 pc-bios/s390-ccw/libc/string/strchr.c > create mode 100644 pc-bios/s390-ccw/libc/string/strcmp.c > create mode 100644 pc-bios/s390-ccw/libc/string/strcpy.c > create mode 100644 pc-bios/s390-ccw/libc/string/strlen.c > create mode 100644 pc-bios/s390-ccw/libc/string/strncasecmp.c > create mode 100644 pc-bios/s390-ccw/libc/string/strncmp.c > create mode 100644 pc-bios/s390-ccw/libc/string/strncpy.c > create mode 100644 pc-bios/s390-ccw/libc/string/strstr.c > create mode 100644 pc-bios/s390-ccw/libc/string/strtok.c > create mode 100644 pc-bios/s390-ccw/libnet/Makefile > create mode 100644 pc-bios/s390-ccw/libnet/args.c > create mode 100644 pc-bios/s390-ccw/libnet/args.h > create mode 100644 pc-bios/s390-ccw/libnet/dhcp.c > create mode 100644 pc-bios/s390-ccw/libnet/dhcp.h > create mode 100644 pc-bios/s390-ccw/libnet/dhcpv6.c > create mode 100644 pc-bios/s390-ccw/libnet/dhcpv6.h > create mode 100644 pc-bios/s390-ccw/libnet/dns.c > create mode 100644 pc-bios/s390-ccw/libnet/dns.h > create mode 100644 pc-bios/s390-ccw/libnet/ethernet.c > create mode 100644 pc-bios/s390-ccw/libnet/ethernet.h > create mode 100644 pc-bios/s390-ccw/libnet/icmpv6.c > create mode 100644 pc-bios/s390-ccw/libnet/icmpv6.h > create mode 100644 pc-bios/s390-ccw/libnet/ipv4.c > create mode 100644 pc-bios/s390-ccw/libnet/ipv4.h > create mode 100644 pc-bios/s390-ccw/libnet/ipv6.c > create mode 100644 pc-bios/s390-ccw/libnet/ipv6.h > create mode 100644 pc-bios/s390-ccw/libnet/ndp.c > create mode 100644 pc-bios/s390-ccw/libnet/ndp.h > create mode 100644 pc-bios/s390-ccw/libnet/netapps.h > create mode 100644 pc-bios/s390-ccw/libnet/netload.c > create mode 100644 pc-bios/s390-ccw/libnet/tcp.c > create mode 100644 pc-bios/s390-ccw/libnet/tcp.h > create mode 100644 pc-bios/s390-ccw/libnet/tftp.c > create mode 100644 pc-bios/s390-ccw/libnet/tftp.h > create mode 100644 pc-bios/s390-ccw/libnet/time.h > create mode 100644 pc-bios/s390-ccw/libnet/timer.c > create mode 100644 pc-bios/s390-ccw/libnet/udp.c > create mode 100644 pc-bios/s390-ccw/libnet/udp.h > create mode 100644 pc-bios/s390-ccw/sbrk.c > create mode 100644 pc-bios/s390-ccw/virtio-net.c >
On 27.06.2017 18:50, Farhan Ali 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? > > IMHO 75k is not that huge compared to the Linux based netboot image. True. I was just surprised that the size was now three times as big as before, but when you compare it to the huge size of a Linux kernel + initrd, 75k are of course close to nothing. >> - 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? > > Can't it be extended to support HTTP boot? Not so easily, since you need TCP support for this first. And TCP is way more complex to implement when compared with UDP. Thomas
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.Neat :) > > 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 > or the dnsmasq tftp server configured by libvirt (SCNR) > 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? The size may be less of an issue than the general overhead for initialization. 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? > > - 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). 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. > > - 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. > > Thomas > > [...] -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
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
On 27.06.2017 23:40, Thomas Huth wrote: [...] >>> - 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. > In order to be consumable, the network boot should support the most common configurations. I would think that most network boot servers are setup as PXE boot servers using pxelinux configs. It will do no good to tell system administrators to have a totally different setup for s390 boot clients. If the firmware doesn't support it we will have to fall back to provide a Linux-based fat netboot image to the pxelinux handling :-(. >> 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 > -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On 28.06.2017 09:28, Viktor Mihajlovski wrote: > On 27.06.2017 23:40, Thomas Huth wrote: > [...] >>>> - 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. >> > In order to be consumable, the network boot should support the most > common configurations. I would think that most network boot servers are > setup as PXE boot servers using pxelinux configs. Are you really sure about the popularity of pxelinux? It's just one flavor of secondary stage network boot loaders - which also only exist on x86 so far, as far as I know. You can also use other loaders like grub2 or gPXE there instead. And other architectures also do not use pxelinux. For example on PowerPC, you normally use yaboot or grub2 as secondary stage boot loader via network instead. > It will do no good to tell system administrators to have a totally> different setup for s390 boot clients. Trying to mimic pxelinux in the firmware still sounds wrong to me. That might also cause some confusion, e.g. if something in the config file is not fully supported (like menus?), or people might start wondering where to get the pxelinux binary itself for s390x ... Maybe it would be better to port the pxelinux binary to s390x? > If the firmware doesn't support it we will have to fall > back to provide a Linux-based fat netboot image to the pxelinux handling > :-(. So far I haven't seen such a Linux-based netboot image yet ([1] mentions pxelinux, but not what software should be used to parse the config file), ... do you have a pointer to the software that parses the pxelinux config file there? Thomas [1] https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg04333.html
On 28.06.2017 10:02, Thomas Huth wrote: > On 28.06.2017 09:28, Viktor Mihajlovski wrote: >> On 27.06.2017 23:40, Thomas Huth wrote: >> [...] >>>>> - 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. >>> >> In order to be consumable, the network boot should support the most >> common configurations. I would think that most network boot servers are >> setup as PXE boot servers using pxelinux configs. > > Are you really sure about the popularity of pxelinux? It's just one > flavor of secondary stage network boot loaders - which also only exist > on x86 so far, as far as I know. And it seems like it also only works with legacy BIOSes, i.e. you can not use it on EFI-only systems, if I've got that right: https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-Using-GRUB2 So I guess the significance of pxelinux will very likely decrease in the next years... Thomas
On 28.06.2017 12:56, Thomas Huth wrote: > On 28.06.2017 10:02, Thomas Huth wrote: >> On 28.06.2017 09:28, Viktor Mihajlovski wrote: >>> On 27.06.2017 23:40, Thomas Huth wrote: >>> [...] >>>>>> - 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. >>>> >>> In order to be consumable, the network boot should support the most >>> common configurations. I would think that most network boot servers are >>> setup as PXE boot servers using pxelinux configs. >> >> Are you really sure about the popularity of pxelinux? It's just one >> flavor of secondary stage network boot loaders - which also only exist >> on x86 so far, as far as I know. > > And it seems like it also only works with legacy BIOSes, i.e. you can > not use it on EFI-only systems, if I've got that right: > > https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-Using-GRUB2 > > So I guess the significance of pxelinux will very likely decrease in > the next years... > Maybe, but supposed goners tend to linger more often than not. I.e., the syslinux project offers a EFI bootloader called syslinux.efi equivalent to the pexelinux.0 BIOS loader. Further, the OPAL firmware of newer POWER systems embeds petitboot and thus offers PXELINUX-compatible network boot as well. I appreciate the idea of a proper BOOTP implementation though, so maybe a compromise could be to start off with your proposal with the slight modification that the final boot action is controlled by the bootfile content (file magic), similar to what you suggested in order to support both insfile and binary kernel. PXELINUX emulation could be triggered by a specially crafted bootfile then. What do you think? > Thomas > -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On 28.06.2017 17:02, Viktor Mihajlovski wrote: > On 28.06.2017 12:56, Thomas Huth wrote: >> On 28.06.2017 10:02, Thomas Huth wrote: >>> On 28.06.2017 09:28, Viktor Mihajlovski wrote: >>>> On 27.06.2017 23:40, Thomas Huth wrote: >>>> [...] >>>>>>> - 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. >>>>> >>>> In order to be consumable, the network boot should support the most >>>> common configurations. I would think that most network boot servers are >>>> setup as PXE boot servers using pxelinux configs. >>> >>> Are you really sure about the popularity of pxelinux? It's just one >>> flavor of secondary stage network boot loaders - which also only exist >>> on x86 so far, as far as I know. >> >> And it seems like it also only works with legacy BIOSes, i.e. you can >> not use it on EFI-only systems, if I've got that right: >> >> https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-Using-GRUB2 >> >> So I guess the significance of pxelinux will very likely decrease in >> the next years... >> > Maybe, but supposed goners tend to linger more often than not. I.e., the > syslinux project offers a EFI bootloader called syslinux.efi equivalent > to the pexelinux.0 BIOS loader. > Further, the OPAL firmware of newer POWER systems embeds petitboot and > thus offers PXELINUX-compatible network boot as well. OK, true, ... you're slowly get me convinced that this pxelinux.cfg stuff is maybe not such a bad idea after all ... So I guess supporting at least the basic commands from the pxelinux config file would be appropriate... (the full set of commands is huge, see http://www.syslinux.org/wiki/index.php?title=Config ) > I appreciate the idea of a proper BOOTP implementation though, so maybe > a compromise could be to start off with your proposal with the slight > modification that the final boot action is controlled by the bootfile > content (file magic), similar to what you suggested in order to support > both insfile and binary kernel. PXELINUX emulation could be triggered by > a specially crafted bootfile then. What do you think? Yes, something like this could work: 1) Do DHCP to get TFTP server address and boot file name 2) Load the boot file from the TFTP server to address 0 3) If the boot file name ended with ".ins" or ".INS" (and the content starts with the "* " magic), treat it as an .INS file and load the files that are listed in there accordingly 4) If the boot file looks like a kernel, start it directly 5) If not successful in 3 or 4, start looking for a pxelinux config file by trying to download the config files as specified in http://www.syslinux.org/wiki/index.php?title=PXELINUX#Configuration and then parse the file and load the kernel + initrd accordingly. Quite a bit of work, so I'll continue to ignore 5 for the first versions, but I agree now that it can certainly be added later. Thomas
On 29.06.2017 09:58, Thomas Huth wrote: > On 28.06.2017 17:02, Viktor Mihajlovski wrote: >> On 28.06.2017 12:56, Thomas Huth wrote: >>> On 28.06.2017 10:02, Thomas Huth wrote: >>>> On 28.06.2017 09:28, Viktor Mihajlovski wrote: >>>>> On 27.06.2017 23:40, Thomas Huth wrote: >>>>> [...] >>>>>>>> - 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. >>>>>> >>>>> In order to be consumable, the network boot should support the most >>>>> common configurations. I would think that most network boot servers are >>>>> setup as PXE boot servers using pxelinux configs. >>>> >>>> Are you really sure about the popularity of pxelinux? It's just one >>>> flavor of secondary stage network boot loaders - which also only exist >>>> on x86 so far, as far as I know. >>> >>> And it seems like it also only works with legacy BIOSes, i.e. you can >>> not use it on EFI-only systems, if I've got that right: >>> >>> https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-Using-GRUB2 >>> >>> So I guess the significance of pxelinux will very likely decrease in >>> the next years... >>> >> Maybe, but supposed goners tend to linger more often than not. I.e., the >> syslinux project offers a EFI bootloader called syslinux.efi equivalent >> to the pexelinux.0 BIOS loader. >> Further, the OPAL firmware of newer POWER systems embeds petitboot and >> thus offers PXELINUX-compatible network boot as well. > > OK, true, ... you're slowly get me convinced that this pxelinux.cfg > stuff is maybe not such a bad idea after all ... So I guess supporting > at least the basic commands from the pxelinux config file would be > appropriate... (the full set of commands is huge, see > http://www.syslinux.org/wiki/index.php?title=Config ) > >> I appreciate the idea of a proper BOOTP implementation though, so maybe >> a compromise could be to start off with your proposal with the slight >> modification that the final boot action is controlled by the bootfile >> content (file magic), similar to what you suggested in order to support >> both insfile and binary kernel. PXELINUX emulation could be triggered by >> a specially crafted bootfile then. What do you think? > > Yes, something like this could work: > > 1) Do DHCP to get TFTP server address and boot file name > 2) Load the boot file from the TFTP server to address 0 > 3) If the boot file name ended with ".ins" or ".INS" (and the content > starts with the "* " magic), treat it as an .INS file and load the > files that are listed in there accordingly > 4) If the boot file looks like a kernel, start it directly > 5) If not successful in 3 or 4, start looking for a pxelinux config > file by trying to download the config files as specified in > http://www.syslinux.org/wiki/index.php?title=PXELINUX#Configuration > and then parse the file and load the kernel + initrd accordingly. > > Quite a bit of work, so I'll continue to ignore 5 for the first > versions, but I agree now that it can certainly be added later. That sounds more than fair. Thanks! > > Thomas > -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
© 2016 - 2024 Red Hat, Inc.