Re: Restrictions of libnet (was: Re: VW ELF loader)

[Thomas Huth <thuth@redhat.com>]

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 <thuth@redhat.com> wrote:
>>>
>>>> On 04/02/2020 00.26, Paolo Bonzini wrote:
>>>>>
>>>>>
>>>>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <aik@ozlabs.ru
>>>>> <mailto:aik@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