Re: [PATCH v5 25/36] mm/memory_hotplug: support N_MEMORY_PRIVATE node hotplug

Qiqi Li <[email protected]>
Newsgroups dev.linux.lists.nvdimm,dev.linux.lists.damon,dev.linux.lists.driver-core,org.kernel.vger.cgroups,org.kernel.vger.kvm,org.kernel.vger.linux-cxl,org.kernel.vger.linux-debuggers,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm
Message-ID <[email protected]>
Hi Gregory,

On 7/21/2026 3:34 AM, Gregory Price wrote:

> Add add_private_memory_driver_managed() to let modules hotplug
> memory onto an N_MEMORY_PRIVATE node they control.

I am trying to understand how the nid passed to
add_private_memory_driver_managed() is expected to be provisioned.

From what I can see, both node_private_register() and
__add_memory_resource() require the nid to already be present in
node_possible_map. My understanding is therefore that this patch
supports hotplugging private memory onto an existing possible node,
rather than creating a new possible node ID at runtime.

For example, in the use case I am looking at, the device's private
node is not described by firmware. Would its nid need to be reserved
during early NUMA initialization, or is there another mechanism that
I may have missed?

Also, could you please Cc me on future revisions of this series?
I would appreciate it and would be happy to follow the work:)

Thanks,
Qiqi
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.