On Tue, Jul 7, 2020 at 11:22 PM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote: [..] > > > Thanks for your suggestion, > > > Could I wrap the codes and let memory_add_physaddr_to_nid simply invoke > > > phys_to_target_node()? > > > > I think it needs to be the reverse. phys_to_target_node() should call > > memory_add_physaddr_to_nid() by default, but fall back to searching > > reserved memory address ranges in memblock. See phys_to_target_node() > > in arch/x86/mm/numa.c. That one uses numa_meminfo instead of memblock, > > but the principle is the same i.e. that a target node may not be > > represented in memblock.memory, but memblock.reserved. I'm working on > > a patch to provide a function similar to get_pfn_range_for_nid() that > > operates on reserved memory. > > Do we really need yet another memblock iterator? > I think only x86 has memory that is not in memblock.memory but only in > memblock.reserved. Well, that's what led me here. EFI has introduced a memory attribute called "EFI Special Purpose Memory". I mapped it to a new Linux concept called Soft Reserved memory (commit b617c5266eed "efi: Common enable/disable infrastructure for EFI soft reservation"). The driver I want to claim that memory, device-dax, wants to be able to look up numa information for an address range that is marked reserved in memblock. The device-dax facility has the ability to either let userspace map a device, or assign the memory backing that device to the page allocator. In both scenarios the driver needs numa info to either populate the 'numa_node' property of the device in sysfs, or to pass an node-id to add_memory_resource() when it is hot-plugged. I was thwarted by the lack of phys_to_target_node() on arm64, and rather than add another stub like memory_add_physaddr_to_nid() I wanted to see if it could be solved properly / generically with memblock data.
