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
