Re: [PATCH qemu v5] spapr: Kill SLOF

[Alexey Kardashevskiy]

On 23/01/2020 16:11, David Gibson wrote:
> On Wed, Jan 22, 2020 at 06:14:37PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 22/01/2020 17:32, David Gibson wrote:
>>> On Tue, Jan 21, 2020 at 06:25:36PM +1100, Alexey Kardashevskiy wrote:
>>>>
>>>>
>>>> On 21/01/2020 16:11, David Gibson wrote:
>>>>> On Fri, Jan 10, 2020 at 01:09:25PM +1100, Alexey Kardashevskiy wrote:
>>>>>> The Petitboot bootloader is way more advanced than SLOF is ever going to
>>>>>> be as Petitboot comes with the full-featured Linux kernel with all
>>>>>> the drivers, and initramdisk with quite user friendly interface.
>>>>>> The problem with ditching SLOF is that an unmodified pseries kernel can
>>>>>> either start via:
>>>>>> 1. kexec, this requires presence of RTAS and skips
>>>>>> ibm,client-architecture-support entirely;
>>>>>> 2. normal boot, this heavily relies on the OF1275 client interface to
>>>>>> fetch the device tree and do early setup (claim memory).
>>>>>>
>>>>>> This adds a new bios-less mode to the pseries machine: "bios=on|off".
>>>>>> When enabled, QEMU does not load SLOF and jumps to the kernel from
>>>>>> "-kernel".
>>>>>
>>>>> I don't love the name "bios" for this flag, since BIOS tends to refer
>>>>> to old-school x86 firmware.  Given the various plans we're considering
>>>>> the future, I'd suggest "firmware=slof" for the current in-guest SLOF
>>>>> mode, and say "firmware=vof" (Virtual Open Firmware) for the new
>>>>> model.  We can consider firmware=petitboot or firmware=none (for
>>>>> direct kexec-style boot into -kernel) or whatever in the future
>>>>
>>>> Ok. We could also enforce default loading addresses for SLOF/kernel/grub
>>>> and drop "kernel-addr", although it is going to be confusing if it
>>>> changes in not so obvious way...
>>>
>>> Yes, I think that would be confusing, so I think adding the
>>> kernel-addr override is a good idea, I'd just like it split out for
>>> clarity.
>>>
>>>> In fact, I will ideally need 3 flags:
>>>> -bios: on|off to stop loading SLOF;
>>>> -kernel-addr: 0x0 for slof/kernel; 0x20000 for grub;
>>>
>>> I'm happy for that one to be separate from the "firmware style"
>>> option.
>>>
>>>> -kernel-translate-hack: on|off - as grub is linked to run from 0x20000
>>>> and it only works when placed there, the hack breaks it.
>>>
>>> Hrm.  I don't really understand what this one is about.  That doesn't
>>> really seem like something the user would ever want to fiddle with
>>> directly.
>>
>> This allows loading grub, or actually any elf (not that I have anything
>> else in mind that just grub but still) which is not capable of
>> relocating itself.
> 
> Ok, why would we ever not want that?


Typical vmlinux is:

[fstn1-p1 kernel]$ readelf --sections ~/pbuild/kernel-le-guest/vmlinux |
head -n 100
There are 54 section headers, starting at offset 0x1027d0b8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .head.text        PROGBITS         c000000000000000  00010000
       0000000000008000  0000000000000000  AX       0     0     128
  [ 2] .text             PROGBITS         c000000000008000  00018000
       0000000000ea2c50  0000000000000000  AX       0     0     256
  [ 3] .rodata           PROGBITS         c000000000eb0000  00ec0000
       00000000002f4b58  0000000000000000  WA       0     0     128
  [ 4] .gnu.hash         GNU_HASH         c0000000011a4b58  011b4b58
       000000000000001c  0000000000000000   A      27     0     8

  [ 5] .pci_fixup        PROGBITS         c0000000011a4b78  011b4b78
       0000000000003438  0000000000000000   A       0     0     8
  [ 6] __param           PROGBITS         c0000000011a7fb0  011b7fb0
       0000000000003fe8  0000000000000000  WA       0     0     8

  [ 7] __modver          PROGBITS         c0000000011abf98  011bbf98
       0000000000000118  0000000000000000  WA       0     0     8



This - c000000000xxxxxx - is where QEMU will try loading the kernel if
we did not have that translate_kernel_address.


> 
>>>> Or we can pass grub via -bios and not via -kernel but strictly speaking
>>>> there is still a firmware - that new 20 bytes blob so it would not be
>>>> accurate.
>>>>
>>>> We can put this all into a single
>>>> -firmware slof|vof|grub|linux. Not sure.
>>>
>>> I'm not thinking of "grub" as a separate option - that would be the
>>> same as "vof".  Using vof + no -kernel we'd need to scan the disks in
>>> the same way SLOF does, and look for a boot partition, which will
>>> probably contain a GRUB image. 
>>
>> I was hoping we can avoid that by allowing
>> "-kernel grub" and let grub do filesystems and MBR/GPT.
> 
> I don't want that to be the only way, because I want the GRUB
> installed by the OS installer to be the GRUB we use.


Then it means implementing filesystems in the OF client in QEMU. Quite a
lot.




-- 
Alexey