Re: VW ELF loader

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3562 bytes --]

On Sat, Feb 01, 2020 at 08:04:25PM +0100, Paolo Bonzini wrote:
> On 01/02/20 14:39, Alexey Kardashevskiy wrote:
> > QEMU needs to load GRUB from the disk. The current workaround is to read
> > it from qcow2, save in a file and then call load_elf(). Not nice.
> > 
> > 2 problems with that.
> > 
> > 1. when load_elf calls address_space_write() - I need to know where and
> > how much RAM was used to mark this memory "used" for the OF client
> > interface (/memory@0/available FDT property). So I'll need "preload()"
> > hook.
> > 
> > 2. (bigger) GRUB comes from PReP partition which is 8MB. load_elf{32|64}
> > consumes filename, not a memory pointer nor a "read_fn" callback - so I
> > thought I need a "read_fn" callback.
> > 
> > And then I discovered that load_elf actually maps the passed file. And
> > here I got lost.
> > 
> > Why does not load_elf just map the entire file and parse the bits? It
> > still reads chunks with seek+read and then it maps the file in a loop
> > potentially multiple times - is this even correct? Passing "fd" around
> > is weird.
> 
> QEMU must not load GRUB from disk, that's the firmware's task.  If you
> want to kill SLOF, you can rewrite it, but loading the kernel GRUB from
> disk within QEMU is a bad idea: the next feature you'll be requested to
> implement will be network boot, and there's no way to do that in QEMU.

So.. I'm going to dispute this.  Or at least dispute that writing "the
firmware" as part of qemu isn't a feasible strategy.  At least in the
case of the "pseries" machine type, and possibly some other explicitly
paravirt machine types.

I do agree that we should leave firmware things to firmware when we're
implementing a real hardware platform and can therefore (at least in
theory) run the same firmware binary under qemu as for the real
hardware.

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.

In PowerVM the environment is implemented with a substantial firmware
as well as hypervisor.  How those two communicate is in closed code,
it's not documented anywhere public, and I suspect it's not even
documented anywhere internal to IBM.

So, for qemu we've taken a different approach.  Since the beginning,
the runtime component of the firmware (RTAS) has been implemented as a
20 byte shim which simply forwards it to a hypercall implemented in
qemu.  The boottime firmware component is SLOF - but a build that's
specific to qemu, and has always needed to be updated in sync with
it.  Even though we've managed to limit the amount of runtime
communication we need between qemu and SLOF, there's some, and it's
become increasingly awkward to handle as we've implemented new features.

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.

That's what killing slof is about.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]