[Top][All Lists]

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

Re: VW ELF loader

From: David Gibson
Subject: Re: VW ELF loader
Date: Mon, 3 Feb 2020 12:31:11 +1100

On Sun, Feb 02, 2020 at 06:38:59PM +0100, Paolo Bonzini wrote:
> Il dom 2 feb 2020, 12:51 Alexey Kardashevskiy <address@hidden> ha scritto:
> > > 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.
> >
> > What is exactly the problem with netboot? I can hook up the OF's "net" to
> > a backend (as I do for serial console and
> > blockdev, in boot order)
> Who provides the OpenFirmware entry point when you remove SLOF and boot
> directly into grub?

We do the same thing as we do for RTAS.  We have a tiny (20 byte) stub
for the client interface entry point which forwards client interface
calls to a hypercall which we implement in qemu.

> Or alternatively it is possible with my patchset to load petitboot (kernel
> > + intramdisk, the default way of booting
> > POWER8/9 baremetal systems) and that thing can do whole lot of things, we
> > can consider it as a replacement for ROMs from
> > devices (or I misunderstood what kind of netboot you meant).
> >
> Why wouldn't that have the same issue as SLOF that you describe below (I
> honestly don't understand anything of it, but that's not your fault :-)).

Because having it's own full understanding of the hardware (via its
linux kernel), petitboot doesn't have to shared data with the
hypervisor to the extent that SLOF needs to.

> Paolo
> > > You should be able to reuse quite a lot of code from both
> > > pc-bios/s390-ccw (for virtio drivers) and kvm-unit-tests (for device
> > > tree parsing).  You'd have to write the glue code for PCI hypercalls,
> > > and adapt virtio.c for virtio-pci instead of virtio-ccw.
> >
> > The reason for killing SLOF is to keep one device tree for the entire boot
> > process including
> > ibm,client-architecture-support with possible (and annoying) configuration
> > reboots. Having another firware won't help
> > with that.
> >
> > Also the OF1275 client interface is the way for the client to get
> > net/block device without need to have drivers, I'd
> > like to do just this and skip the middle man (QEMU device and guest driver
> > in firmware/bootloader).
> >
> > I'll post another RFC tomorrow to give a better idea.

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

Attachment: signature.asc
Description: PGP signature

reply via email to

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