Re: [qemu-s390x] [PATCH v2 0/4] pc-bios/s390-ccw: Allow network booting via pxelinux.cfg

[Thomas Huth]

On 11.06.2018 11:08, Viktor VM Mihajlovski wrote:
> On 07.06.2018 14:22, Thomas Huth wrote:
>> This patch series adds pxelinux.cfg-style network booting to the s390-ccw
>> firmware. The core pxelinux.cfg loading and parsing logic has recently
>> been merged to SLOF, so these patches now just have to make sure to call
>> the right functions to get the config file loaded and parsed. Once this is
>> done, the kernel and initrd are loaded separately, and are then glued
>> together in RAM.
>>
>> v2:
>>  - Update SLOF submodule now that the git mirror is in sync again
>>  - Last parameter to tftp_get_error_info() must not be NULL
>>  - Check CC when calling STSI, and use a #define for the UUID offset
>>  - Only support files with the magic "# pxelinux" string comment when
>>    trying to guess the contents of a file that has been downloaded via
>>    the "bootfile" DHCP parameter. This is just for developers' convenience,
>>    the official way to specify pxelinux.cfg files is to use the DHCP
>>    options 209 and 210 instead.
>>
>> Thomas Huth (4):
>>   roms: Update SLOF submodule to current status
>>   pc-bios/s390-ccw/net: Update code for the latest changes in SLOF
>>   pc-bios/s390-ccw/net: Add support for pxelinux-style config files
>>   pc-bios/s390-ccw/net: Try to load pxelinux.cfg file accoring to the
>>     UUID
>>
>>  pc-bios/s390-ccw/netboot.mak |   9 +-
>>  pc-bios/s390-ccw/netmain.c   | 226 
>> +++++++++++++++++++++++++++++--------------
>>  roms/SLOF                    |   2 +-
>>  3 files changed, 162 insertions(+), 75 deletions(-)
>>
> I tested the series both with a self-created pxelinux.0 blob (to verify
> backward compatibility) and without an existing pxelinux.0 file (to
> force the standard pxelinux pattern). Both worked as expected, although
> the built-in search took significantly longer (timeout?).
> 
> Tested-by: Viktor Mihajlovski <address@hidden>

Thanks a lot for the testing!

Hmm, I've got no real clue why there should be a big difference in the
amount of time here ... is there maybe a lot of unrelated broadcast
network traffic from other hosts going on in that network where you've
tested it? It could be that the virtio-net driver of the s390-ccw bios
can not deal with that situation very well yet. You could try to
increase the "64" in virtio_net_init() in pc-bios/s390-ccw/virtio-net.c
to see whether it makes a difference. Or if you've got some spare time,
could you maybe run Wireshark on the server side to have a look at the
time-stamps of the related packets, and to see whether there are
duplicated TFTP read requests? This could indicate that the firmware
missed a packet and thus ran into a timeout.

 Thomas

PS: After I posted v1 of the patch set, you reported on IRC that you saw
a problem with a corrupted initrd download or something similar. Is that
problem now fixed for you?