Re: VW ELF loader

[David Gibson]

On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote:
> On 05/02/20 07:06, David Gibson wrote:
> > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote:
> >> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <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.
> > 
> > Urgh... first, I don't really see how you'd do that.  OF's whole
> > device model is based around the device tree.  So implementing OF
> > driver interactions would require the firmware to do a bunch of
> > internal hypercalls to do all the DT stuff, which brings us back to a
> > much more complex and active interface between firmware and hypervisor
> > than we really want.
> 
> I'm really sorry if what I am saying is stupid; but I was thinking of a
> firmware entrypoint like
> 
>       if (op == "read" || op == "write")
>               do_driver_stuff(op);
>       else
>               hypercall();

Um... I'm not really clear on where you're imagining this going.  In
the OF model, device operations are done by "opening" a device tree
node then executing methods on it, so you can't really even get to
this point without a bunch of DT stuff.

> This is not even close to pseudocode, but hopefully enough to give the
> idea.  Perhaps what I don't understand is why you can't start the
> firmware with r3 pointing to the device tree, and stash it for when you
> leave control to GRUB.

Again, I'm not even really sure what you mean by this.  We already
enter SLOF with r3 pointing to a device tree.  I'm not sure what
stashing it would accomplish.  GRUB as it stands expects an OF style
entry point though, not a flat tree style entry point.

Are you suggesting rewriting it to run in that environment?  That
might be an option, but it's certainly not easy.  We'd have to write
"native" grub drivers for all the devices we care about, rather than
calling into OF for them.  Maybe there's some x86 code we could
already use here?  I don't know how much GRUB relies on the BIOS or
UEFI for device access on PC.

> Or to put it another way, what petitboot does
> that you cannot do in your own firmware.

So, part of the confusion is that there are two things we're
considering here and it's not really clear yet how much they overlap.

1) Is using petitboot as our bootloader.  That gives us basically
every driver, network protocol and tool we could ever want.  However,
it gets to the next stage via kexec(), so it can only support OSes
which are kexec()able - i.e. Linux.  This is mostly speculation at
this point.

2) Having a way of booting existing clients - i.e. those that expect
OF-style entry conditions - but without having to maintain a blob of
Forth.  The "kill slof" patches are a concrete, if limited, attempt at
this.

> > Second, drivers are kind of where we'd get the most benefit by putting
> > them in qemu: from qemu we can just talk to the device backends
> > directly so we don't need to re-abstract the differences between
> > different device models of the same type.
> 
> Of course, but drivers are easy to write.

I'm not really sure I agree with you there.

> Not as easy as s390 probably
> because you'd have to link in libfdt and so on, but between
> kvm-unit-tests and s390-ccw there's quite a bit of code can be reused.

Maybe, but I'm not really sure where you're picturing it fitting in.

> >> You can generalize and reuse the s390 code. All you have to write is the
> >> PCI scan and virtio-pci setup.
> > 
> > If we assume virtio only.
> 
> Do you actually need something else?

Well.. that's an interesting question.

> The TTY can use the simple
> getchar/putchar hypercalls,

Yes... though if people attach a graphical console they might be
pretty surprised that they don't get anything on there.  Supporting
that means adding vga, which adds substantial complexity (especially
since text mode isn't really a thing for a vga on a POWER machine).

> and sPAPR-vSCSI clients can keep using SLOF.

We can possibly ignore the spapr virtual devices.  They seemed like
they'd be important for people transitioning from guests under
PowerVM, but honestly I'm not sure they've ever been used much.

We do support emulated (or passthrough) PCI devices.  I don't know if
they're common enough that we need boot support for them.  Netboot
from a vfio network adaptor might be something people want.

USB storage is also a fairly likely candidate, and that would add a
*lot* of extra complexity, since we'd need both the HCD and storage
drivers.

-- 
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

signature.asc
Description: PGP signature