| Message ID | 20191118105319.7658-5-lvivier@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PULL,v2,1/6] ppc: Add intc_destroy() handlers to SpaprInterruptController/PnvChip | expand |
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
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 >
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 >> >
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 >>> >> >
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
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,
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 --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);