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

[Thomas Huth <thuth@redhat.com>]

On 11.06.2018 14:03, Viktor VM Mihajlovski wrote:
> On 11.06.2018 13:12, Thomas Huth wrote:
>> 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 <mihajlov@linux.vnet.ibm.com>
>>
>> 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.
> FWIW: I'm using the isolated libvirt network on an otherwise idle host,
> so it's unlikely that there's interference. If I find the time I'll have
> a look at the traffic.

If you have the time to look at the traffic, could you please also check
the TFTP block size option that is negotiated at the beginning of the
TFTP transfer? If this other client is negotiating a transfer block size
that is bigger than the one from the s390-ccw firmware, this could
explain the differences in the downloading time, too.

libnet from SLOF currently uses a block size of 1428. This is the size
where all TFTP data should still fit nicely into one ethernet packet -
and this is also the size which is still supported by all TFTP servers
that support the blksize option. But theoretically it's also possible to
use a bigger block sizes if both, the server and the client support
fragmented UDP packets. Unfortunately, as far as I can see, SLOF's
libnet does not support fragmented UDP packets, so we can't increase the
block size here anymore so easily.

Can you tell which tftp client you are using in your other pxelinux.0
blob? (busybox tftp? HPA-tftp ?)

 Thomas