On Sun, Feb 02, 2020 at 06:38:59PM +0100, Paolo Bonzini wrote: > Il dom 2 feb 2020, 12:51 Alexey Kardashevskiy <a...@ozlabs.ru> 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_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
