Re: [PULL v2 4/6] spapr: Add /chosen to FDT only at reset time to preserve kernel and initramdisk

[Alexey Kardashevskiy]

On 04/12/2019 03:09, Laurent Vivier wrote:
> 
> Bad reply, the problem is with
> 
> "spapr: Render full FDT on ibm,client-architecture-support"


https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=3e4c1b34b8af2dcebde57e548c94417e5e20e1cc;hb=HEAD#l265

A "bit ugly" became really ugly as before we were only patching
interrupt-map for PHB (7 cells per line) only but now we have to patch
(or, rather, skip) the PCI bridge interrupt-map (9 cells per line).

Fixing now...


> 
> Sorry,
> Laurent
> 
> On 03/12/2019 16:57, Laurent Vivier wrote:
>> On 18/11/2019 11:53, Laurent Vivier wrote:
>>> From: Alexey Kardashevskiy <address@hidden>
>>>
>>> Since "spapr: Render full FDT on ibm,client-architecture-support" we build
>>> the entire flatten device tree (FDT) twice - at the reset time and
>>> when "ibm,client-architecture-support" (CAS) is called. The full FDT from
>>> CAS is then applied on top of the SLOF internal device tree.
>>>
>>> This is mostly ok, however there is a case when the QEMU is started with
>>> -initrd and for some reason the guest decided to move/unpack the init RAM
>>> disk image - the guest correctly notifies SLOF about the change but
>>> at CAS it is overridden with the QEMU initial location addresses and
>>> the guest may fail to boot if the original initrd memory was changed.
>>>
>>> This fixes the problem by only adding the /chosen node at the reset time
>>> to prevent the original QEMU's linux,initrd-start/linux,initrd-end to
>>> override the updated addresses.
>>>
>>> This only treats /chosen differently as we know there is a special case
>>> already and it is unlikely anything else will need to change /chosen at CAS
>>> we are better off not touching /chosen after we handed it over to SLOF.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>>> Message-Id: <address@hidden>
>>> Signed-off-by: David Gibson <address@hidden>
>>> Signed-off-by: Laurent Vivier <address@hidden>
>>> ---
>>>  hw/ppc/spapr.c | 25 +++++++++++++++----------
>>>  1 file changed, 15 insertions(+), 10 deletions(-)
>>>
>>
>> This patch breaks pseries boot when we use a pci-bridge (since v4.2.0-rc0):
>>
>> ...
>>     -device pci-bridge,id=pci_bridge1,bus=pci.0,addr=0x3,chassis_nr=1 \
>>     -device virtio-scsi-pci,bus=pci_bridge1 \
>> ...
>>
>> OF stdout device is: /vdevice/vty@71000000
>> Preparing to boot Linux version 5.4.0-rc3+ (lvivier@localhost) (gcc
>> version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)) #2 SMP Wed Nov 13
>> 09:08:20 EST 2019
>> Detected machine type: 0000000000000101
>> command line: BOOT_IMAGE=/vmlinuz-5.4.0-rc3+ root=/dev/mapper/rhel-root
>> ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap
>> Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
>> Calling ibm,client-architecture-support...
>>
>> ( 300 ) Data Storage Exception [ 1dc5f230 ]
>>
>>
>>     R0 .. R7           R8 .. R15         R16 .. R23         R24 .. R31
>> 8000000000001000   000000001e477010   0000000000000000   000000001dc17500
>> 000000001e67afe0   0000000020000004   0000000000000000   000000001dc1bf88
>> 000000001dc21800   000000001dc5f248   000000001e477010   0000000000000003
>> 000000001dc61000   000000001e78dc2d   000000001dc1c158   000000000000f001
>> 0000000000000000   a000000000000001   0000000000008000   000000001e67b060
>> 000000001dc5f230   0000000000000000   000000000000f003   ffffffffffffffff
>> 000000001e745860   0000000000000000   0000000000000006   000000001dbf48f8
>> 000000001dc5f248   0000000000000000   000000001e67b050   000000001dc1c350
>>
>>     CR / XER           LR / CTR          SRR0 / SRR1        DAR / DSISR
>>         80000808   000000001dbf34d4   000000001dbf4194   0000000020000004
>> 0000000020000000   000000001dbf48f8   8000000000001000           40000000
>>
>>
>> 4a >
>>
>> Thanks,
>> Laurent
>>
> 

-- 
Alexey