Hi Shawn,
On 15/12/2023 02:50, Shawn Anastasio wrote:
Hi Julien,
Thank you for the feedback. Most of your points will be addressed by
following your suggestion of moving ARM's bootfdt.c to common, but I
wanted to respond with a few points of clarification.
On 12/1/23 5:23 PM, Julien Grall wrote:
* fdt_get_mem_rsv_paddr(), this is part of the DT is used to reserve
memory. This was superseed to /reserved-memory, but I wonder how
widespread this is on PPC?
As far as I can tell, the DT reserve memory map is not used on
PPC/PowerNV. This information is instead communicated through
`reserved-memory` nodes in the DT itself, which the existing code
handles.
On Arm, there is a mix between using /memreserve (found by Xen via
fdt_get_mem_rsv_paddr() and reserved-memory.
Looking at Linux, it seems that it will try to parse /memreserve in PPC
and I have found a few DT using it:
42sh> ack memreserve
boot/dts/currituck.dts
13:/memreserve/ 0x01f00000 0x00100000; // spin table
boot/dts/akebono.dts
14:/memreserve/ 0x01f00000 0x00100000; // spin table
boot/dts/iss4xx-mpic.dts
17:/memreserve/ 0x01f00000 0x00100000;
boot/dts/mpc836x_mds.dts
10:/memreserve/ 00000000 1000000;
boot/dts/wii.dts
17: * contiguous RAM range and will BUG() if the memreserve is outside
20:/*/memreserve/ 0x10000000 0x0004000;*/ /* DSP RAM */
I guess we are not targetting any of those hardwares. Even if this is
the case, I don't think we can simply ignore the node. If you don't want
to handle them, then I would at least suggest to add a check in Xen to
confirm the /memreserve/ is empty.
Better to catch such DT early rather than debugging a memory corruption
later on :).
Cheers,
--
Julien Grall
