Re: VW ELF loader

[Alexey Kardashevskiy]

On 3/2/20 8:12 pm, Paolo Bonzini wrote:
> On 03/02/20 02:28, David Gibson wrote:
>> But "pseries" is different.  We're implementing the PAPR platform,
>> which describes an OS environment that's presented by a combination of
>> a hypervisor and firmware.  The features it specifies *require*
>> collaboration between the firmware and the hypervisor.
> 
> Which features are these?

RTAS: PCI handling - MSI allocations, config space, interrupts
(XICS/XIVE) - we do it in QEMU right now so this went unnoticed but
ideally there should have been a RTAS binary lot bigger than those 20
bytes (never even had a chance to look at what IBM pHyp does).

OF CI: ibm,client-architecture-support and all these spapr-vlan/vty/scsi
paradevices - we do not really need any driver between GRUB and QEMU -
the OF interface defines enough.

Resource allocation - we allocate some in QEMU (PCI bus numbers
assignment and PHB windows) but assign BARs and bridge windows in SLOF
(boottime) or Linux (hotplug). We could just let Linux do this or do
this in QEMU.

Interrupt map - QEMU does this for PHB (as a host interrupt controller
is a parent) and SLOF does it for PCI bridges (they have PHB or other
bridges as parents so they do it themselves), except of course PCI hot
plug after the guest started but Linux has not fetched the device tree.

All this is manageable but quite hard to maintain while benefits of such
separation of hypervisor code are not clear.


>> So really, the question isn't whether we implement things in firmware
>> or in qemu.  It's whether we implement the firmware functionality as
>> guest cpu code, which needs to be coded to work with a limited
>> environment, built with a special toolchain, then emulated with TCG.
>> Or, do we just implement it in normal C code, with a full C library,
>> and existing device and backend abstractions inside qemu.
> 
> ... which is adding almost 2000 lines of new code to the host despite
> the following limitations:

Kind of. But it replaces a log bigger chunk of SLOF, easy to read and it
works faster. Just virtio-scsi/net drivers are about 1700 lines and we
do need them at all with the proposed patches (or I missed the bigger
picture again and we need them?).

Also Linux needs only roughly a half of this. One idea was to hack GRUB
to run in the userspace from initrd with petitboot-alike kernel, and
carry this small kernel with a franken-GRUB with QEMU, then extra code
goes to GRUB and then those folks become unhappy :)


>> 4. no networking in OF CI at all;
>> 5. no vga;
>> 6. no disk partitions in CI, i.e. no commas to select a partition -
>> this relies on a bootloader accessing the disk as a whole;

This is not going to be a lot really, especially supporting partitions -
the code is practically there already as I needed it to find GRUB, and
GRUB does the rest asking very little from the firmware to work.

btw what is the common way of netbooting in x86? NIC ROM or GRUB (but
this would be a disk anyway)? Can we consider having a precompiled GRUB
image somewhere in pc-bios/ to use for netboot? Or Uboot would do (it is
already in pc-bios/, no?), I suppose?


> and of course:
> 
>> 7. "interpret" (executes passed forth expression) does nothing as in this
>> environment grub only uses it for switching cursor off and similar tasks.
> 
> In other words you're not dropping SLOF, you're really dropping
> OpenFirmware completely.

What is the exact benefit of having OpenFirmware's "interpret"? The rest
is there as far as known clients are concerned. FreeBSD is somewhere
between GRUB and Linux, and we never truly supported AIX as it has (or
at least used to) fixes for pHyp firmware bugs which we never cared to
simulate in SLOF.

I totally get why people want a firmware, it makes perfect sense when
emulating bare metal machine (such as the powernv machine type in QEMU)
but spapr is not the case.



>  It's little more than what ARM does.
> 
> Paolo
> 

-- 
Alexey