Bad reply, the problem is with
"spapr: Render full FDT on ibm,client-architecture-support" Sorry, Laurent On 03/12/2019 16:57, Laurent Vivier wrote: > On 18/11/2019 11:53, Laurent Vivier wrote: >> From: Alexey Kardashevskiy <[email protected]> >> >> 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 <[email protected]> >> Message-Id: <[email protected]> >> Signed-off-by: David Gibson <[email protected]> >> Signed-off-by: Laurent Vivier <[email protected]> >> --- >> 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 >
