On 05/02/2020 06.30, David Gibson wrote: > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote: >> On 04/02/2020 09.54, Cornelia Huck wrote: >>> On Tue, 4 Feb 2020 07:16:46 +0100 >>> Thomas Huth <th...@redhat.com> wrote: >>> >>>> On 04/02/2020 00.26, Paolo Bonzini wrote: >>>>> >>>>> >>>>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <a...@ozlabs.ru >>>>> <mailto:a...@ozlabs.ru>> ha scritto: >>>>> >>>>> Speaking seriously, what would I put into the guest? >>>>> >>>>> Only things that would be considered drivers. Ignore the partitions >>>>> issue for now so that you can just pass the device tree services to QEMU >>>>> with hypercalls. >>>>> >>>>> Netboot's dhcp/tftp/ip/ipv6 client? It is going to be another SLOF, >>>>> smaller but adhoc with only a couple of people knowing it. >>>>> >>>>> >>>>> You can generalize and reuse the s390 code. All you have to write is the >>>>> PCI scan and virtio-pci setup. >>>> >>>> Well, for netbooting, the s390-ccw bios uses the libnet code from SLOF, >>>> so re-using this for a slim netboot client on ppc64 would certainly be >>>> feasible (especially since there are also already virtio drivers in SLOF >>>> that are written in C), but I think it is not very future proof. The >>>> libnet from SLOF only supports UDP, and no TCP. So for advanced boot >>>> scenarios like booting from HTTP or even HTTPS, you need something else >>>> (i.e. maybe grub is the better option, indeed). >>> >>> That makes me wonder what that means for s390: We're inheriting >>> libnet's limitations, but we don't have grub -- do we need to come up >>> with something different? Or improve libnet? >> >> I don't think that it makes sense to re-invent the wheel yet another >> time and write yet another TCP implementation (which is likely quite a >> bit of work, too, especially if you also want to do secure HTTPS in the >> end). So yes, in the long run (as soon as somebody seriously asks for >> HTTP booting on s390x) we need something different here. >> >> Now looking at our standard s390x bootloader zipl - this has been giving >> us a headache a couple of times in the past, too (from a distro point of >> view since s390x is the only major platform left that does not use grub, >> but also from a s390-ccw bios point of view, see e.g. >> https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03046.html and >> related discussions). >> >> So IMHO the s390x world should move towards grub2, too. We could e.g. >> link it initially into the s390-ccw bios bios ... and if that works out >> well, later also use it as normal bootloader instead of zipl (not sure >> if that works in all cases, though, IIRC there were some size >> constraints and stuff like that). > > petitboot would be another reasonable thing to consider here. Since > it's Linux based, you have all the drivers you have there. It's not > quite grub, but it does at least parse the same configuration files. > > You do need kexec() of course, I don't know if you have that already > for s390 or not.
AFAIK we have kexec on s390. So yes, petitboot would be another option for replacing the s390-ccw bios. But when it comes to LPARs and z/VMs, I don't think it's really feasible to replace the zipl bootloader there with petitboot, so in that case grub2 still sounds like the better option to me. Thomas