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

Thomas Huth posted 14 patches 6 years, 9 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/1498564100-10045-1-git-send-email-thuth@redhat.com
Test FreeBSD passed
Test s390x passed
There is a newer version of this series
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
[Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by David Hildenbrand 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Christian Borntraeger 6 years, 9 months ago
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?


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Christian Borntraeger 6 years, 9 months ago
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.


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Alexander Graf 6 years, 9 months ago

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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Gerd Hoffmann 6 years, 9 months ago
  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.

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Farhan Ali 6 years, 9 months ago
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
>


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Viktor Mihajlovski 6 years, 9 months ago
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


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Viktor Mihajlovski 6 years, 9 months ago
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


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Viktor Mihajlovski 6 years, 9 months ago
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


Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Thomas Huth 6 years, 9 months ago
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

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Posted by Viktor Mihajlovski 6 years, 9 months ago
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