Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.13 3/4] pc-bios/s390-ccw/net: Add support for pxelinux-style config files

[Thomas Huth <thuth@redhat.com>]

On 19.04.2018 14:40, Viktor VM Mihajlovski wrote:
> On 19.04.2018 10:17, Thomas Huth wrote:
>> On 19.04.2018 09:41, Viktor VM Mihajlovski wrote:
>>> On 18.04.2018 14:31, Thomas Huth wrote:
>>>> Since it is quite cumbersome to manually create a combined kernel with
>>>> initrd image for network booting, we now support loading via pxelinux
>>>> configuration files, too. In these files, the kernel, initrd and command
>>>> line parameters can be specified seperately, and the firmware then takes
>>>> care of glueing everything together in memory after the files have been
>>>> downloaded.
> [...]
>>>> +static int net_try_direct_tftp_load(filename_ip_t *fn_ip)
>>>> +{
>>>> +    int rc;
>>>> +    void *baseaddr = (void *)0x2000;  /* Load right after the low-core */
>>>> +
>>>> +    rc = tftp_load(fn_ip, baseaddr, KERNEL_MAX_SIZE - (long)baseaddr);
>>>> +
>>>> +    if (rc > 0 && rc < sizeof(cfgbuf) - 1) {
>>>> +        /* Check whether it is a configuration file instead of a kernel */
>>> That's interesting because treating the bootfile as pxe-ish config is
>>> what DPM does. Which means that with this change the processor
>>> architecture type 0x1f (Basic) will turn into a superset of 0x20
>>> (Extended).
>>
>> Is there any reference available what "basic" and "extended" exactly
>> mean? I just know that there are these two values registered by you at
>> the IANA:
>>
>> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#processor-architecture
>>
>> ... but I haven't seen a description of the differences of these two
>> values yet.
>>
> Yep, the IANA stuff is pretty terse for all architectures. In a
> nutshell: 0x1f is standard DHCP-based boot (bootfile is a single
> executable binary) and 0x20 serves a pxe-style config file instead.

Can 0x20 also still handle binary files, or only pxe-style config files?

> In fact, "processor architecture identifier" is a misnomer, as it
> describes a pair of processor architecture and firmware.

Yeah, I know ... it's even worse nowadays, it's processor + firmware +
TCP/IP protocol (HTTP vs. TFTP) ... we should have properly untangled
that when doing RFC 5970, but it was already hard enough to get that
accepted in the current shape, so we missed to clean up the mess from
RFC 4578 / PXE :-(

> Since the QEMU firmware has two significant extensions now (insfile and
> direct config file loading), it might be worthwhile to add a new
> identifier value (say s390 QEMU PC-BIOS or similar) announcing the new
> capabilities, so that a boot server admin can setup her system accordingly.

Not sure ... too many processory-architecture-type entries might also
rather be too confusing for the users? ... so if 0x20 can also handle
binary files like 0x1f, I'd maybe simply go with 0x20 and mainly promote
pxelinux config files in the documentation?

 Thomas