[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Huth
Subject: Re: Restrictions of libnet (was: Re: VW ELF loader)
Date: Wed, 5 Feb 2020 07:24:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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 <address@hidden> wrote:
>>>> On 04/02/2020 00.26, Paolo Bonzini wrote:
>>>>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <address@hidden
>>>>> <mailto:address@hidden>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]