On Mon, Jan 15, 2024 at 02:14:14PM +0000, Jiaxun Yang wrote: > > > 在 2024/1/15 01:25, Huang Pei 写道: > > On Sun, Jan 14, 2024 at 11:58:25AM +0000, Jiaxun Yang wrote: > > > > > > 在 2024/1/14 08:53, Huang Pei 写道: > > > > On Sat, Jan 13, 2024 at 11:59:11AM +0000, Jiaxun Yang wrote: > > > [...] > > > > In my test system with kunlun firmware they are actually covered by SYSRAM > > > > type. > > > > IMO, better to add those memory to memblock as well in your case. > > > > > > > > My test machine is PMON-based 3B1500, the SMBIOS_TABLE located in > > > > 0xfffe000-0xfffe7ff, which is not included in SYSTEM_RAM_LOW(0x200000- > > > > 0xeffffff), I think we need a check like, > > > > ---------------------------------------------------------------------- > > > > if(memblock_is_region_memory(addr, size)) > > > > memblock_reserve(addr, size); > > > > ---------------------------------------------------------------------- > > > > to support both cases; > > > Then we are running into ordering issue. memblock_add of SYSRAM may later > > > then reservation. > > > What about unconditionally add those ranges to memblock? As it's certain > > > that those regions will > > > be RAM. > > > > > I think we can do szmem twice, one for memblock.memory, the other for > > memblock_reserve. > IMO this is a little bit insane. > LoongArch made a workaround to set all reserved memory to node zero [1]. > > [1]: > https://lore.kernel.org/all/20230911092810.3108092-1-chenhuacai@xxxxxxxxxxx/ > I think they forgot MIPS totally. Their fix is right, because all the reserved memory is located on Node 0 by now. If we keep reserved memory within range of the memoryblock.memory and keep this conresponcy, then there would not be this bug. My fix is just another way to keep this conresponcy and make the memory ownership more clear between kernel and firmware. > Thanks > > -- > --- > Jiaxun Yang
