From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f9Cqb-0002Qy-7H for qemu-devel@nongnu.org; Thu, 19 Apr 2018 12:55:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f9CqY-0005iH-F5 for qemu-devel@nongnu.org; Thu, 19 Apr 2018 12:55:49 -0400 References: <1524054707-20663-1-git-send-email-thuth@redhat.com> <1524054707-20663-4-git-send-email-thuth@redhat.com> <2d59a139-3bdd-4b4e-882c-5cf845488eda@linux.vnet.ibm.com> From: Thomas Huth Message-ID: <475ea222-cc03-16e4-0f50-f89cf2bfae6f@redhat.com> Date: Thu, 19 Apr 2018 18:55:34 +0200 MIME-Version: 1.0 In-Reply-To: <2d59a139-3bdd-4b4e-882c-5cf845488eda@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.13 3/4] pc-bios/s390-ccw/net: Add support for pxelinux-style config files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Viktor VM Mihajlovski , Christian Borntraeger , qemu-s390x@nongnu.org Cc: Collin Walling , Cornelia Huck , qemu-devel@nongnu.org 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 wi= th >>>> initrd image for network booting, we now support loading via pxelinu= x >>>> configuration files, too. In these files, the kernel, initrd and com= mand >>>> line parameters can be specified seperately, and the firmware then t= akes >>>> care of glueing everything together in memory after the files have b= een >>>> downloaded. > [...] >>>> +static int net_try_direct_tftp_load(filename_ip_t *fn_ip) >>>> +{ >>>> + int rc; >>>> + void *baseaddr =3D (void *)0x2000; /* Load right after the low= -core */ >>>> + >>>> + rc =3D tftp_load(fn_ip, baseaddr, KERNEL_MAX_SIZE - (long)basea= ddr); >>>> + >>>> + if (rc > 0 && rc < sizeof(cfgbuf) - 1) { >>>> + /* Check whether it is a configuration file instead of a ke= rnel */ >>> 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.x= html#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 accordin= gly. 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