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

[Viktor VM Mihajlovski]

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 <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.
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.
> 
>  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?
> 
Yes, it was my bad. I used an older kernel with the following problem
https://lkml.org/lkml/2017/3/13/683.

-- 
Regards,
  Viktor Mihajlovski