diff mbox series

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

Message ID 20191118105319.7658-5-lvivier@redhat.com
State New
Headers show
Series [PULL,v2,1/6] ppc: Add intc_destroy() handlers to SpaprInterruptController/PnvChip | expand

Commit Message

Laurent Vivier Nov. 18, 2019, 10:53 a.m. UTC 
From: Alexey Kardashevskiy <aik@ozlabs.ru>

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 <aik@ozlabs.ru>
Message-Id: <20191024041308.5673-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
---
 hw/ppc/spapr.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

Comments

Laurent Vivier Dec. 3, 2019, 3:57 p.m. UTC | #1 
On 18/11/2019 11:53, Laurent Vivier wrote:
> From: Alexey Kardashevskiy <aik@ozlabs.ru>
> 
> 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 <aik@ozlabs.ru>
> Message-Id: <20191024041308.5673-1-aik@ozlabs.ru>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  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
Laurent Vivier Dec. 3, 2019, 4:09 p.m. UTC | #2 
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 <aik@ozlabs.ru>
>>
>> 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 <aik@ozlabs.ru>
>> Message-Id: <20191024041308.5673-1-aik@ozlabs.ru>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>> ---
>>  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 Kardashevskiy Dec. 4, 2019, 4:23 a.m. UTC | #3 
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 <aik@ozlabs.ru>
>>>
>>> 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 <aik@ozlabs.ru>
>>> Message-Id: <20191024041308.5673-1-aik@ozlabs.ru>
>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>>> ---
>>>  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 Kardashevskiy Dec. 4, 2019, 4:40 a.m. UTC | #4 
On 04/12/2019 15:23, Alexey Kardashevskiy wrote:
> 
> 
> 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...


Basically, this:


diff --git a/board-qemu/slof/fdt.fs b/board-qemu/slof/fdt.fs
index 3e4c1b34b8af..463a2a8c0c2d 100644
--- a/board-qemu/slof/fdt.fs
+++ b/board-qemu/slof/fdt.fs
@@ -300,8 +300,13 @@ fdt-claim-reserve
    \ ." Replacing in " dup node>path type cr
    >r
    s" interrupt-map" r@ get-property 0= IF
-      ( old new prop-addr prop-len  R: node )
-      fdt-replace-interrupt-map
+      dup e00 = IF
+          ( old new prop-addr prop-len  R: node )
+          fdt-replace-interrupt-map
+      ELSE
+         2drop
+          ."  no idea what this is" cr
+      THEN
    THEN





> 
> 
>>
>> Sorry,
>> Laurent
>>
>> On 03/12/2019 16:57, Laurent Vivier wrote:
>>> On 18/11/2019 11:53, Laurent Vivier wrote:
>>>> From: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>
>>>> 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 <aik@ozlabs.ru>
>>>> Message-Id: <20191024041308.5673-1-aik@ozlabs.ru>
>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>>>> ---
>>>>  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
>>>
>>
>
Laurent Vivier Dec. 4, 2019, 10:32 a.m. UTC | #5 
On 04/12/2019 05:40, Alexey Kardashevskiy wrote:
> 
> 
> On 04/12/2019 15:23, Alexey Kardashevskiy wrote:
>>
>>
>> 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...
> 
> 
> Basically, this:
> 
> 
> diff --git a/board-qemu/slof/fdt.fs b/board-qemu/slof/fdt.fs
> index 3e4c1b34b8af..463a2a8c0c2d 100644
> --- a/board-qemu/slof/fdt.fs
> +++ b/board-qemu/slof/fdt.fs
> @@ -300,8 +300,13 @@ fdt-claim-reserve
>     \ ." Replacing in " dup node>path type cr
>     >r
>     s" interrupt-map" r@ get-property 0= IF
> -      ( old new prop-addr prop-len  R: node )
> -      fdt-replace-interrupt-map
> +      dup e00 = IF
> +          ( old new prop-addr prop-len  R: node )
> +          fdt-replace-interrupt-map
> +      ELSE
> +         2drop
> +          ."  no idea what this is" cr
> +      THEN
>     THEN

This does not fix the problem for me.

Thanks,
Laurent
Alexey Kardashevskiy Dec. 5, 2019, 4:26 a.m. UTC | #6 
On 04/12/2019 21:32, Laurent Vivier wrote:
> On 04/12/2019 05:40, Alexey Kardashevskiy wrote:
>>
>>
>> On 04/12/2019 15:23, Alexey Kardashevskiy wrote:
>>>
>>>
>>> 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...
>>
>>
>> Basically, this:
>>
>>
>> diff --git a/board-qemu/slof/fdt.fs b/board-qemu/slof/fdt.fs
>> index 3e4c1b34b8af..463a2a8c0c2d 100644
>> --- a/board-qemu/slof/fdt.fs
>> +++ b/board-qemu/slof/fdt.fs
>> @@ -300,8 +300,13 @@ fdt-claim-reserve
>>     \ ." Replacing in " dup node>path type cr
>>     >r
>>     s" interrupt-map" r@ get-property 0= IF
>> -      ( old new prop-addr prop-len  R: node )
>> -      fdt-replace-interrupt-map
>> +      dup e00 = IF
>> +          ( old new prop-addr prop-len  R: node )
>> +          fdt-replace-interrupt-map
>> +      ELSE
>> +         2drop
>> +          ."  no idea what this is" cr
>> +      THEN
>>     THEN
> 
> This does not fix the problem for me.

That's strange, does it crash the same way?

Anyway I made 2 patches:
https://patchwork.ozlabs.org/patch/1204467/
https://patchwork.ozlabs.org/patch/1204468/

Please give them a try. Thanks,
Laurent Vivier Dec. 5, 2019, 8:52 a.m. UTC | #7 
On 05/12/2019 05:26, Alexey Kardashevskiy wrote:
> 
> 
> On 04/12/2019 21:32, Laurent Vivier wrote:
>> On 04/12/2019 05:40, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 04/12/2019 15:23, Alexey Kardashevskiy wrote:
>>>>
>>>>
>>>> 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...
>>>
>>>
>>> Basically, this:
>>>
>>>
>>> diff --git a/board-qemu/slof/fdt.fs b/board-qemu/slof/fdt.fs
>>> index 3e4c1b34b8af..463a2a8c0c2d 100644
>>> --- a/board-qemu/slof/fdt.fs
>>> +++ b/board-qemu/slof/fdt.fs
>>> @@ -300,8 +300,13 @@ fdt-claim-reserve
>>>     \ ." Replacing in " dup node>path type cr
>>>     >r
>>>     s" interrupt-map" r@ get-property 0= IF
>>> -      ( old new prop-addr prop-len  R: node )
>>> -      fdt-replace-interrupt-map
>>> +      dup e00 = IF
>>> +          ( old new prop-addr prop-len  R: node )
>>> +          fdt-replace-interrupt-map
>>> +      ELSE
>>> +         2drop
>>> +          ."  no idea what this is" cr
>>> +      THEN
>>>     THEN
>>
>> This does not fix the problem for me.
> 
> That's strange, does it crash the same way?

No, you're right. I didn't test the good image. I've re-tested correctly
and it works.

> 
> Anyway I made 2 patches:
> https://patchwork.ozlabs.org/patch/1204467/
> https://patchwork.ozlabs.org/patch/1204468/
> 
> Please give them a try. Thanks,

I've applied them in series and after the second is applied all works fine.

Thanks,
Laurent
diff mbox series

Patch

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 94f9d27096af..e076f6023c73 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -917,7 +917,7 @@  static bool spapr_hotplugged_dev_before_cas(void)
     return false;
 }
 
-static void *spapr_build_fdt(SpaprMachineState *spapr);
+static void *spapr_build_fdt(SpaprMachineState *spapr, bool reset);
 
 int spapr_h_cas_compose_response(SpaprMachineState *spapr,
                                  target_ulong addr, target_ulong size,
@@ -939,7 +939,7 @@  int spapr_h_cas_compose_response(SpaprMachineState *spapr,
 
     size -= sizeof(hdr);
 
-    fdt = spapr_build_fdt(spapr);
+    fdt = spapr_build_fdt(spapr, false);
     _FDT((fdt_pack(fdt)));
 
     if (fdt_totalsize(fdt) + sizeof(hdr) > size) {
@@ -1197,7 +1197,7 @@  static void spapr_dt_hypervisor(SpaprMachineState *spapr, void *fdt)
     }
 }
 
-static void *spapr_build_fdt(SpaprMachineState *spapr)
+static void *spapr_build_fdt(SpaprMachineState *spapr, bool reset)
 {
     MachineState *machine = MACHINE(spapr);
     MachineClass *mc = MACHINE_GET_CLASS(machine);
@@ -1297,7 +1297,9 @@  static void *spapr_build_fdt(SpaprMachineState *spapr)
     spapr_dt_rtas(spapr, fdt);
 
     /* /chosen */
-    spapr_dt_chosen(spapr, fdt);
+    if (reset) {
+        spapr_dt_chosen(spapr, fdt);
+    }
 
     /* /hypervisor */
     if (kvm_enabled()) {
@@ -1305,11 +1307,14 @@  static void *spapr_build_fdt(SpaprMachineState *spapr)
     }
 
     /* Build memory reserve map */
-    if (spapr->kernel_size) {
-        _FDT((fdt_add_mem_rsv(fdt, KERNEL_LOAD_ADDR, spapr->kernel_size)));
-    }
-    if (spapr->initrd_size) {
-        _FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base, spapr->initrd_size)));
+    if (reset) {
+        if (spapr->kernel_size) {
+            _FDT((fdt_add_mem_rsv(fdt, KERNEL_LOAD_ADDR, spapr->kernel_size)));
+        }
+        if (spapr->initrd_size) {
+            _FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base,
+                                  spapr->initrd_size)));
+        }
     }
 
     /* ibm,client-architecture-support updates */
@@ -1718,7 +1723,7 @@  static void spapr_machine_reset(MachineState *machine)
      */
     fdt_addr = MIN(spapr->rma_size, RTAS_MAX_ADDR) - FDT_MAX_SIZE;
 
-    fdt = spapr_build_fdt(spapr);
+    fdt = spapr_build_fdt(spapr, true);
 
     rc = fdt_pack(fdt);