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? 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 :-)). 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. > > > -- > Alexey > >
