qemu-devel
[Top][All Lists]
Advanced

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

Re: VW ELF loader


From: Alexey Kardashevskiy
Subject: Re: VW ELF loader
Date: Fri, 7 Feb 2020 10:23:45 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0


On 06/02/2020 19:29, Paolo Bonzini wrote:
> On 05/02/20 06:58, David Gibson wrote:
>>> Yes, SLOF is big and slow.  petitboot is not petit at all either, and
>>> has the disadvantage that you have to find a way to run GRUB afterwards.
>> Well, not usually.  Petitboot parses grub configuration itself, which
>> means that generally from the OS / installer point of view it looks
>> like grub, even though it's not from the actual bootstrapping point of
>> view.
> 
> Ok, sorry about that.  I need to learn a bit more.
> 
>>>  But would a similarly minimal OF implementation (no network, almost no
>>> interpret so no Forth, device tree built entirely in the host, etc.) be
>>> just as big and slow?
>>
>> So, as actual OF implementations go, SLOF is already pretty minimal
>> (hence "Slim Line Open Firmware").  If there's no Forth, it's really
>> not OF any more, just something mimicing some of OF's interfaces.
> 
> Right, not unlike what you get with vof=on. :)  I'm not against at all
> that idea.  I just don't understand what you refer to below as (2).
> Does petitboot not have the problem because it kexecs the new kernel?


Petitboot does not have this problem *if* it runs without SLOF, i.e.
directly via -kernel and -initrd and uses OF CI (cut down version, about
v3-v4 of my patchset, without block devices and grub lookup). In this
case there is one device tree instance, fully synchronized with the
machine state.

If there is still SLOF and (2) is happening, then petitboot is screwed
as any other kernel.


> Paolo
> 
>> But the difficulty of SLOF isn't really its bigness or slowness in any
>> case (the slowness is just an additional irritation).  The two big
>> issues are 1) that it's written in an obscure language and 2)
>> synchronizing its state with things that require host side
>> involvement.
>>
>> Rewriting a minimal guest side not-OF would partly address (1) (but
>> there's still the logistical pain of having to build and insert it),
>> and wouldn't address (2) at all.
> 

-- 
Alexey



reply via email to

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