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

Qiqi Li <[email protected]> Thu, 6 Aug 2026 11:30:08 +0800
Newsgroups org.kernel.vger.cgroups,dev.linux.lists.damon,dev.linux.lists.driver-core,dev.linux.lists.nvdimm,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