On 04/02/2020 09:56, Paolo Bonzini wrote:
>
>
> Il lun 3 feb 2020, 23:36 Alexey Kardashevskiy <a...@ozlabs.ru
> <mailto:a...@ozlabs.ru>> ha scritto:
>
>
> > What partition formats would have to be supported?
>
> MBR, GPT, is there anything else? "Support" is limited to converting a
> number after command to [start, size] couple. I am not going for file
> systems.
>
> > But honestly I'm
> > more worried about the networking part.
>
> Fair enough.
>
> > 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.
> > 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?
>
> I doubt. We will be getting rid of unnecessary drivers, bus scanning
> code (SCSI, PCI), device tree synchronization.
>
>
> What I mean is, if you write a firmware that exposes a minimal OF device
> interface but runs it in the guest, and does a hypercall for everything
> else, would it be as big and slow as SLOF?
I just did almost that - 20 bytes, fast as a bullet, runs in the guest ;)
Speaking seriously, what would I put into the guest?
The device tree? This is the core problem of the current design - we
need to keep it in sync with QEMU.
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. Other
packages - disk-label, deblocker - I do not see any user for these
except SLOF itself.
--
Alexey
