[PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Yuquan Wang]

acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
with the expectation that numa_cleanup_meminfo moves them to
numa_reserved_meminfo. There is no need for that indirection when it is
known in advance that these unpopulated ranges are meant for
numa_reserved_meminfo in support of future hotplug / CXL provisioning.

Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
ranges directly.

Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
---

Changes in v2 (Thanks to Dan & Alison):
- Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
- Add comments to describe the usage of numa_add_reserved_memblk()
- Updating the commit message to clarify the purpose of the patch

By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.

 drivers/acpi/numa/srat.c     |  2 +-
 include/linux/numa_memblks.h |  1 +
 mm/numa_memblks.c            | 22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 0a725e46d017..751774f0b4e5 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
 		return -EINVAL;
 	}
 
-	if (numa_add_memblk(node, start, end) < 0) {
+	if (numa_add_reserved_memblk(node, start, end) < 0) {
 		/* CXL driver must handle the NUMA_NO_NODE case */
 		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
 			node, start, end);
diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
index dd85613cdd86..991076cba7c5 100644
--- a/include/linux/numa_memblks.h
+++ b/include/linux/numa_memblks.h
@@ -22,6 +22,7 @@ struct numa_meminfo {
 };
 
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
 void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
 
 int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
index ff4054f4334d..541a99c4071a 100644
--- a/mm/numa_memblks.c
+++ b/mm/numa_memblks.c
@@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
 }
 
+/**
+ * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @end: End address of the new memblk
+ *
+ * Add a new memblk to the numa_reserved_meminfo.
+ *
+ * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
+ * against memblock_type information and moves any that intersect reserved
+ * ranges to numa_reserved_meminfo. However, when that information is known
+ * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
+ * to numa_reserved_meminfo directly.
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
+{
+	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
+}
+
 /**
  * numa_cleanup_meminfo - Cleanup a numa_meminfo
  * @mi: numa_meminfo to clean up
-- 
2.34.1

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Andrew Morton]

On Tue,  6 May 2025 14:22:45 +0800 Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:

> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
> By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.

So is this patch dependent upon "LoongArch: Introduce the numa_memblks
conversion"?

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Mike Rapoport]

On Tue, May 06, 2025 at 06:55:44PM -0700, Andrew Morton wrote:
> On Tue,  6 May 2025 14:22:45 +0800 Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:
> 
> > acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> > with the expectation that numa_cleanup_meminfo moves them to
> > numa_reserved_meminfo. There is no need for that indirection when it is
> > known in advance that these unpopulated ranges are meant for
> > numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> > 
> > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> > ranges directly.
> > 
> > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> > ---
> > 
> > Changes in v2 (Thanks to Dan & Alison):
> > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> > - Add comments to describe the usage of numa_add_reserved_memblk()
> > - Updating the commit message to clarify the purpose of the patch
> > 
> > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> 
> So is this patch dependent upon "LoongArch: Introduce the numa_memblks
> conversion"?

Yes, the previous version of this patch failed to build on loongarch.

-- 
Sincerely yours,
Mike.

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Mike Rapoport]

On Tue, May 06, 2025 at 02:22:45PM +0800, Yuquan Wang wrote:
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
> By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 0a725e46d017..751774f0b4e5 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up
> -- 
> 2.34.1
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Jonathan Cameron]

On Tue, 6 May 2025 14:22:45 +0800
Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:

> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
This is v2 take 2.  There were tags on the previous version (pre longarch
change).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

(Also Dan Williams).

Easiest option when this happens is spin a v3 with a change log to
say the loongarch issue is resolved and you picked up tags.


> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
> By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 0a725e46d017..751774f0b4e5 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Yuquan Wang]

On Wed, May 07, 2025 at 05:24:36PM +0100, Jonathan Cameron wrote:
> On Tue, 6 May 2025 14:22:45 +0800
> Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:
> 
> > acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> > with the expectation that numa_cleanup_meminfo moves them to
> > numa_reserved_meminfo. There is no need for that indirection when it is
> > known in advance that these unpopulated ranges are meant for
> > numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> > 
> > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> > ranges directly.
> > 
> > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> This is v2 take 2.  There were tags on the previous version (pre longarch
> change).
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> 
> (Also Dan Williams).
> 
> Easiest option when this happens is spin a v3 with a change log to
> say the loongarch issue is resolved and you picked up tags.
>
Hi Jonathan,

Thanks for your tips. Would this v2 version trigger the kernel test
robot? It seems like only a new version of patch would trigger that.
I would publish v3 of this patch as soon as possible. 

Yuquan
> 
> > ---
> > 
> > Changes in v2 (Thanks to Dan & Alison):
> > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> > - Add comments to describe the usage of numa_add_reserved_memblk()
> > - Updating the commit message to clarify the purpose of the patch
> > 
> > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> > 
> >  drivers/acpi/numa/srat.c     |  2 +-
> >  include/linux/numa_memblks.h |  1 +
> >  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
> >  3 files changed, 24 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > index 0a725e46d017..751774f0b4e5 100644
> > --- a/drivers/acpi/numa/srat.c
> > +++ b/drivers/acpi/numa/srat.c
> > @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> >  		return -EINVAL;
> >  	}
> >  
> > -	if (numa_add_memblk(node, start, end) < 0) {
> > +	if (numa_add_reserved_memblk(node, start, end) < 0) {
> >  		/* CXL driver must handle the NUMA_NO_NODE case */
> >  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
> >  			node, start, end);
> > diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> > index dd85613cdd86..991076cba7c5 100644
> > --- a/include/linux/numa_memblks.h
> > +++ b/include/linux/numa_memblks.h
> > @@ -22,6 +22,7 @@ struct numa_meminfo {
> >  };
> >  
> >  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
> >  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
> >  
> >  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> > diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> > index ff4054f4334d..541a99c4071a 100644
> > --- a/mm/numa_memblks.c
> > +++ b/mm/numa_memblks.c
> > @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
> >  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
> >  }
> >  
> > +/**
> > + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> > + * @nid: NUMA node ID of the new memblk
> > + * @start: Start address of the new memblk
> > + * @end: End address of the new memblk
> > + *
> > + * Add a new memblk to the numa_reserved_meminfo.
> > + *
> > + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> > + * against memblock_type information and moves any that intersect reserved
> > + * ranges to numa_reserved_meminfo. However, when that information is known
> > + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> > + * to numa_reserved_meminfo directly.
> > + *
> > + * RETURNS:
> > + * 0 on success, -errno on failure.
> > + */
> > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> > +{
> > +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> > +}
> > +
> >  /**
> >   * numa_cleanup_meminfo - Cleanup a numa_meminfo
> >   * @mi: numa_meminfo to clean up
> 

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Huacai Chen]

On Thu, May 8, 2025 at 9:47 AM Yuquan Wang
<wangyuquan1236@phytium.com.cn> wrote:
>
> On Wed, May 07, 2025 at 05:24:36PM +0100, Jonathan Cameron wrote:
> > On Tue, 6 May 2025 14:22:45 +0800
> > Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:
> >
> > > acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> > > with the expectation that numa_cleanup_meminfo moves them to
> > > numa_reserved_meminfo. There is no need for that indirection when it is
> > > known in advance that these unpopulated ranges are meant for
> > > numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> > >
> > > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> > > ranges directly.
> > >
> > > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> > This is v2 take 2.  There were tags on the previous version (pre longarch
> > change).
> >
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > (Also Dan Williams).
> >
> > Easiest option when this happens is spin a v3 with a change log to
> > say the loongarch issue is resolved and you picked up tags.
> >
> Hi Jonathan,
>
> Thanks for your tips. Would this v2 version trigger the kernel test
> robot? It seems like only a new version of patch would trigger that.
> I would publish v3 of this patch as soon as possible.

The kernel test robot operates on linux-next, so there's probably no errors now.

Huacai

>
> Yuquan
> >
> > > ---
> > >
> > > Changes in v2 (Thanks to Dan & Alison):
> > > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> > > - Add comments to describe the usage of numa_add_reserved_memblk()
> > > - Updating the commit message to clarify the purpose of the patch
> > >
> > > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> > >
> > >  drivers/acpi/numa/srat.c     |  2 +-
> > >  include/linux/numa_memblks.h |  1 +
> > >  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
> > >  3 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > > index 0a725e46d017..751774f0b4e5 100644
> > > --- a/drivers/acpi/numa/srat.c
> > > +++ b/drivers/acpi/numa/srat.c
> > > @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > >             return -EINVAL;
> > >     }
> > >
> > > -   if (numa_add_memblk(node, start, end) < 0) {
> > > +   if (numa_add_reserved_memblk(node, start, end) < 0) {
> > >             /* CXL driver must handle the NUMA_NO_NODE case */
> > >             pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
> > >                     node, start, end);
> > > diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> > > index dd85613cdd86..991076cba7c5 100644
> > > --- a/include/linux/numa_memblks.h
> > > +++ b/include/linux/numa_memblks.h
> > > @@ -22,6 +22,7 @@ struct numa_meminfo {
> > >  };
> > >
> > >  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
> > >  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
> > >
> > >  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> > > diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> > > index ff4054f4334d..541a99c4071a 100644
> > > --- a/mm/numa_memblks.c
> > > +++ b/mm/numa_memblks.c
> > > @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
> > >     return numa_add_memblk_to(nid, start, end, &numa_meminfo);
> > >  }
> > >
> > > +/**
> > > + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> > > + * @nid: NUMA node ID of the new memblk
> > > + * @start: Start address of the new memblk
> > > + * @end: End address of the new memblk
> > > + *
> > > + * Add a new memblk to the numa_reserved_meminfo.
> > > + *
> > > + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> > > + * against memblock_type information and moves any that intersect reserved
> > > + * ranges to numa_reserved_meminfo. However, when that information is known
> > > + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> > > + * to numa_reserved_meminfo directly.
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, -errno on failure.
> > > + */
> > > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> > > +{
> > > +   return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> > > +}
> > > +
> > >  /**
> > >   * numa_cleanup_meminfo - Cleanup a numa_meminfo
> > >   * @mi: numa_meminfo to clean up
> >
>

[PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Yuquan Wang]

acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
with the expectation that numa_cleanup_meminfo moves them to
numa_reserved_meminfo. There is no need for that indirection when it is
known in advance that these unpopulated ranges are meant for
numa_reserved_meminfo in support of future hotplug / CXL provisioning.

Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
ranges directly.

Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
---

Changes in v2 (Thanks to Dan & Alison):
- Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
- Add comments to describe the usage of numa_add_reserved_memblk()
- Updating the commit message to clarify the purpose of the patch

 drivers/acpi/numa/srat.c     |  2 +-
 include/linux/numa_memblks.h |  1 +
 mm/numa_memblks.c            | 22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 0a725e46d017..751774f0b4e5 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
 		return -EINVAL;
 	}
 
-	if (numa_add_memblk(node, start, end) < 0) {
+	if (numa_add_reserved_memblk(node, start, end) < 0) {
 		/* CXL driver must handle the NUMA_NO_NODE case */
 		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
 			node, start, end);
diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
index dd85613cdd86..991076cba7c5 100644
--- a/include/linux/numa_memblks.h
+++ b/include/linux/numa_memblks.h
@@ -22,6 +22,7 @@ struct numa_meminfo {
 };
 
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
 void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
 
 int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
index ff4054f4334d..541a99c4071a 100644
--- a/mm/numa_memblks.c
+++ b/mm/numa_memblks.c
@@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
 }
 
+/**
+ * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @end: End address of the new memblk
+ *
+ * Add a new memblk to the numa_reserved_meminfo.
+ *
+ * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
+ * against memblock_type information and moves any that intersect reserved
+ * ranges to numa_reserved_meminfo. However, when that information is known
+ * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
+ * to numa_reserved_meminfo directly.
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
+{
+	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
+}
+
 /**
  * numa_cleanup_meminfo - Cleanup a numa_meminfo
  * @mi: numa_meminfo to clean up
-- 
2.34.1

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Mike Rapoport]

On Wed, Apr 09, 2025 at 12:01:21PM +0800, Yuquan Wang wrote:
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 0a725e46d017..751774f0b4e5 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up
> -- 
> 2.34.1
> 
> 

-- 
Sincerely yours,
Mike.

[PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Yuquan Wang]

With numa_add_reserved_memblk(), kernel could add numa_memblk into
numa_reserved_meminfo directly.

acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
with the expectation that numa_cleanup_meminfo moves them to
numa_reserved_meminfo. There is no need for that indirection when it is
known in advance that these unpopulated ranges are meant for
numa_reserved_meminfo in suppot of future hotplug / CXL provisioning.

Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
---

Changes in v2 (Thanks to Dan):
- Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
- Add comments to describe the usage of numa_add_reserved_memblk()
- Provide a more explicit commit message

 drivers/acpi/numa/srat.c     |  2 +-
 include/linux/numa_memblks.h |  1 +
 mm/numa_memblks.c            | 22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 00ac0d7bb8c9..70f1a7c6b54a 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -458,7 +458,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
 		return -EINVAL;
 	}
 
-	if (numa_add_memblk(node, start, end) < 0) {
+	if (numa_add_reserved_memblk(node, start, end) < 0) {
 		/* CXL driver must handle the NUMA_NO_NODE case */
 		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
 			node, start, end);
diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
index dd85613cdd86..991076cba7c5 100644
--- a/include/linux/numa_memblks.h
+++ b/include/linux/numa_memblks.h
@@ -22,6 +22,7 @@ struct numa_meminfo {
 };
 
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
 void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
 
 int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
index ff4054f4334d..541a99c4071a 100644
--- a/mm/numa_memblks.c
+++ b/mm/numa_memblks.c
@@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
 }
 
+/**
+ * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @end: End address of the new memblk
+ *
+ * Add a new memblk to the numa_reserved_meminfo.
+ *
+ * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
+ * against memblock_type information and moves any that intersect reserved
+ * ranges to numa_reserved_meminfo. However, when that information is known
+ * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
+ * to numa_reserved_meminfo directly.
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
+{
+	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
+}
+
 /**
  * numa_cleanup_meminfo - Cleanup a numa_meminfo
  * @mi: numa_meminfo to clean up
-- 
2.34.1

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[kernel test robot]

Hi Yuquan,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]

url:    https://github.com/intel-lab-lkp/linux/commits/Yuquan-Wang/mm-numa_memblks-introduce-numa_add_reserved_memblk/20250328-172428
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20250328092132.2695299-1-wangyuquan1236%40phytium.com.cn
patch subject: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk
config: loongarch-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202503282026.QNaOAK79-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/build_bug.h:5,
                    from include/linux/container_of.h:5,
                    from include/linux/list.h:5,
                    from include/linux/module.h:12,
                    from drivers/acpi/numa/srat.c:10:
   drivers/acpi/numa/srat.c: In function 'acpi_parse_cfmws':
>> drivers/acpi/numa/srat.c:461:13: error: implicit declaration of function 'numa_add_reserved_memblk' [-Wimplicit-function-declaration]
     461 |         if (numa_add_reserved_memblk(node, start, end) < 0) {
         |             ^~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:57:52: note: in definition of macro '__trace_if_var'
      57 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
         |                                                    ^~~~
   drivers/acpi/numa/srat.c:461:9: note: in expansion of macro 'if'
     461 |         if (numa_add_reserved_memblk(node, start, end) < 0) {
         |         ^~


vim +/numa_add_reserved_memblk +461 drivers/acpi/numa/srat.c

   431	
   432	static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
   433					   void *arg, const unsigned long table_end)
   434	{
   435		struct acpi_cedt_cfmws *cfmws;
   436		int *fake_pxm = arg;
   437		u64 start, end;
   438		int node;
   439	
   440		cfmws = (struct acpi_cedt_cfmws *)header;
   441		start = cfmws->base_hpa;
   442		end = cfmws->base_hpa + cfmws->window_size;
   443	
   444		/*
   445		 * The SRAT may have already described NUMA details for all,
   446		 * or a portion of, this CFMWS HPA range. Extend the memblks
   447		 * found for any portion of the window to cover the entire
   448		 * window.
   449		 */
   450		if (!numa_fill_memblks(start, end))
   451			return 0;
   452	
   453		/* No SRAT description. Create a new node. */
   454		node = acpi_map_pxm_to_node(*fake_pxm);
   455	
   456		if (node == NUMA_NO_NODE) {
   457			pr_err("ACPI NUMA: Too many proximity domains while processing CFMWS.\n");
   458			return -EINVAL;
   459		}
   460	
 > 461		if (numa_add_reserved_memblk(node, start, end) < 0) {
   462			/* CXL driver must handle the NUMA_NO_NODE case */
   463			pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
   464				node, start, end);
   465		}
   466		node_set(node, numa_nodes_parsed);
   467	
   468		/* Set the next available fake_pxm value */
   469		(*fake_pxm)++;
   470		return 0;
   471	}
   472	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Dan Williams]

[add loongarch folks, cc linux-cxl ]

kernel test robot wrote:
> Hi Yuquan,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on akpm-mm/mm-everything]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Yuquan-Wang/mm-numa_memblks-introduce-numa_add_reserved_memblk/20250328-172428
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link:    https://lore.kernel.org/r/20250328092132.2695299-1-wangyuquan1236%40phytium.com.cn
> patch subject: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk
> config: loongarch-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/config)
> compiler: loongarch64-linux-gcc (GCC) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202503282026.QNaOAK79-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>    In file included from include/linux/build_bug.h:5,
>                     from include/linux/container_of.h:5,
>                     from include/linux/list.h:5,
>                     from include/linux/module.h:12,
>                     from drivers/acpi/numa/srat.c:10:
>    drivers/acpi/numa/srat.c: In function 'acpi_parse_cfmws':
> >> drivers/acpi/numa/srat.c:461:13: error: implicit declaration of function 'numa_add_reserved_memblk' [-Wimplicit-function-declaration]
>      461 |         if (numa_add_reserved_memblk(node, start, end) < 0) {
>          |             ^~~~~~~~~~~~~~~~~~~~~~~~

So it looks like loongarch was left out of the numa_memblks conversion:
87482708210f ("mm: introduce numa_memblks")

I think the update needed is something like this (untested):

diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index 2b8bd27a852f..cac16c827159 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -183,6 +183,7 @@ config LOONGARCH
 	select MODULES_USE_ELF_RELA if MODULES
 	select NEED_PER_CPU_EMBED_FIRST_CHUNK
 	select NEED_PER_CPU_PAGE_FIRST_CHUNK
+	select NUMA_MEMBLKS
 	select OF
 	select OF_EARLY_FLATTREE
 	select PCI
diff --git a/arch/loongarch/include/asm/numa.h b/arch/loongarch/include/asm/numa.h
index b5f9de9f102e..bbf9f70bd25f 100644
--- a/arch/loongarch/include/asm/numa.h
+++ b/arch/loongarch/include/asm/numa.h
@@ -22,20 +22,6 @@ extern int numa_off;
 extern s16 __cpuid_to_node[CONFIG_NR_CPUS];
 extern nodemask_t numa_nodes_parsed __initdata;
 
-struct numa_memblk {
-	u64			start;
-	u64			end;
-	int			nid;
-};
-
-#define NR_NODE_MEMBLKS		(MAX_NUMNODES*2)
-struct numa_meminfo {
-	int			nr_blks;
-	struct numa_memblk	blk[NR_NODE_MEMBLKS];
-};
-
-extern int __init numa_add_memblk(int nodeid, u64 start, u64 end);
-
 extern void __init early_numa_add_cpu(int cpuid, s16 node);
 extern void numa_add_cpu(unsigned int cpu);
 extern void numa_remove_cpu(unsigned int cpu);
diff --git a/arch/loongarch/kernel/numa.c b/arch/loongarch/kernel/numa.c
index 84fe7f854820..57b21082e893 100644
--- a/arch/loongarch/kernel/numa.c
+++ b/arch/loongarch/kernel/numa.c
@@ -18,6 +18,7 @@
 #include <linux/efi.h>
 #include <linux/irq.h>
 #include <linux/pci.h>
+#include <linux/numa_memblks.h>
 #include <asm/bootinfo.h>
 #include <asm/loongson.h>
 #include <asm/numa.h>

Could someone from the loongarch side propose the fixups needed here so
Yuquan can land this patch?

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Yuquan Wang]

> [add loongarch folks, cc linux-cxl ]
> 
> kernel test robot wrote:
> > Hi Yuquan,
> > 
> > kernel test robot noticed the following build errors:
> > 
> > [auto build test ERROR on akpm-mm/mm-everything]
> > 
> > url:    https://github.com/intel-lab-lkp/linux/commits/Yuquan-Wang/mm-numa_memblks-introduce-numa_add_reserved_memblk/20250328-172428
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> > patch link:    https://lore.kernel.org/r/20250328092132.2695299-1-wangyuquan1236%40phytium.com.cn
> > patch subject: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk
> > config: loongarch-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/config)
> > compiler: loongarch64-linux-gcc (GCC) 14.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202503282026.QNaOAK79-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    In file included from include/linux/build_bug.h:5,
> >                     from include/linux/container_of.h:5,
> >                     from include/linux/list.h:5,
> >                     from include/linux/module.h:12,
> >                     from drivers/acpi/numa/srat.c:10:
> >    drivers/acpi/numa/srat.c: In function 'acpi_parse_cfmws':
> > >> drivers/acpi/numa/srat.c:461:13: error: implicit declaration of function 'numa_add_reserved_memblk' [-Wimplicit-function-declaration]
> >      461 |         if (numa_add_reserved_memblk(node, start, end) < 0) {
> >          |             ^~~~~~~~~~~~~~~~~~~~~~~~
> 
> So it looks like loongarch was left out of the numa_memblks conversion:
> 87482708210f ("mm: introduce numa_memblks")
> 
> I think the update needed is something like this (untested):
> 
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index 2b8bd27a852f..cac16c827159 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -183,6 +183,7 @@ config LOONGARCH
>   select MODULES_USE_ELF_RELA if MODULES
>   select NEED_PER_CPU_EMBED_FIRST_CHUNK
>   select NEED_PER_CPU_PAGE_FIRST_CHUNK
> + select NUMA_MEMBLKS
>   select OF
>   select OF_EARLY_FLATTREE
>   select PCI
> diff --git a/arch/loongarch/include/asm/numa.h b/arch/loongarch/include/asm/numa.h
> index b5f9de9f102e..bbf9f70bd25f 100644
> --- a/arch/loongarch/include/asm/numa.h
> +++ b/arch/loongarch/include/asm/numa.h
> @@ -22,20 +22,6 @@ extern int numa_off;
>  extern s16 __cpuid_to_node[CONFIG_NR_CPUS];
>  extern nodemask_t numa_nodes_parsed __initdata;
>  
> -struct numa_memblk {
> - u64 start;
> - u64 end;
> - int nid;
> -};
> -
> -#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
> -struct numa_meminfo {
> - int nr_blks;
> - struct numa_memblk blk[NR_NODE_MEMBLKS];
> -};
> -
> -extern int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> -
>  extern void __init early_numa_add_cpu(int cpuid, s16 node);
>  extern void numa_add_cpu(unsigned int cpu);
>  extern void numa_remove_cpu(unsigned int cpu);
> diff --git a/arch/loongarch/kernel/numa.c b/arch/loongarch/kernel/numa.c
> index 84fe7f854820..57b21082e893 100644
> --- a/arch/loongarch/kernel/numa.c
> +++ b/arch/loongarch/kernel/numa.c
> @@ -18,6 +18,7 @@
>  #include <linux/efi.h>
>  #include <linux/irq.h>
>  #include <linux/pci.h>
> +#include <linux/numa_memblks.h>
>  #include <asm/bootinfo.h>
>  #include <asm/loongson.h>
>  #include <asm/numa.h>
> 
> Could someone from the loongarch side propose the fixups needed here so
> Yuquan can land this patch?

Hi, Dan

Should I wait for Loongarch folks's replies or draft a new patch for Loongarch
to introduce numa_memblks according to your suggested code?

Yuquan



信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Dan Williams]

Yuquan Wang wrote:
> 
> > [add loongarch folks, cc linux-cxl ]
> > 
> > kernel test robot wrote:
> > > Hi Yuquan,
> > > 
> > > kernel test robot noticed the following build errors:
> > > 
> > > [auto build test ERROR on akpm-mm/mm-everything]
> > > 
> > > url:    https://github.com/intel-lab-lkp/linux/commits/Yuquan-Wang/mm-numa_memblks-introduce-numa_add_reserved_memblk/20250328-172428
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> > > patch link:    https://lore.kernel.org/r/20250328092132.2695299-1-wangyuquan1236%40phytium.com.cn
> > > patch subject: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk
> > > config: loongarch-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/config)
> > > compiler: loongarch64-linux-gcc (GCC) 14.2.0
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282026.QNaOAK79-lkp@intel.com/reproduce)
> > > 
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202503282026.QNaOAK79-lkp@intel.com/
> > > 
> > > All errors (new ones prefixed by >>):
> > > 
> > >    In file included from include/linux/build_bug.h:5,
> > >                     from include/linux/container_of.h:5,
> > >                     from include/linux/list.h:5,
> > >                     from include/linux/module.h:12,
> > >                     from drivers/acpi/numa/srat.c:10:
> > >    drivers/acpi/numa/srat.c: In function 'acpi_parse_cfmws':
> > > >> drivers/acpi/numa/srat.c:461:13: error: implicit declaration of function 'numa_add_reserved_memblk' [-Wimplicit-function-declaration]
> > >      461 |         if (numa_add_reserved_memblk(node, start, end) < 0) {
> > >          |             ^~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > So it looks like loongarch was left out of the numa_memblks conversion:
> > 87482708210f ("mm: introduce numa_memblks")
> > 
> > I think the update needed is something like this (untested):
> > 
> > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> > index 2b8bd27a852f..cac16c827159 100644
> > --- a/arch/loongarch/Kconfig
> > +++ b/arch/loongarch/Kconfig
> > @@ -183,6 +183,7 @@ config LOONGARCH
> >   select MODULES_USE_ELF_RELA if MODULES
> >   select NEED_PER_CPU_EMBED_FIRST_CHUNK
> >   select NEED_PER_CPU_PAGE_FIRST_CHUNK
> > + select NUMA_MEMBLKS
> >   select OF
> >   select OF_EARLY_FLATTREE
> >   select PCI
> > diff --git a/arch/loongarch/include/asm/numa.h b/arch/loongarch/include/asm/numa.h
> > index b5f9de9f102e..bbf9f70bd25f 100644
> > --- a/arch/loongarch/include/asm/numa.h
> > +++ b/arch/loongarch/include/asm/numa.h
> > @@ -22,20 +22,6 @@ extern int numa_off;
> >  extern s16 __cpuid_to_node[CONFIG_NR_CPUS];
> >  extern nodemask_t numa_nodes_parsed __initdata;
> >  
> > -struct numa_memblk {
> > - u64 start;
> > - u64 end;
> > - int nid;
> > -};
> > -
> > -#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
> > -struct numa_meminfo {
> > - int nr_blks;
> > - struct numa_memblk blk[NR_NODE_MEMBLKS];
> > -};
> > -
> > -extern int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > -
> >  extern void __init early_numa_add_cpu(int cpuid, s16 node);
> >  extern void numa_add_cpu(unsigned int cpu);
> >  extern void numa_remove_cpu(unsigned int cpu);
> > diff --git a/arch/loongarch/kernel/numa.c b/arch/loongarch/kernel/numa.c
> > index 84fe7f854820..57b21082e893 100644
> > --- a/arch/loongarch/kernel/numa.c
> > +++ b/arch/loongarch/kernel/numa.c
> > @@ -18,6 +18,7 @@
> >  #include <linux/efi.h>
> >  #include <linux/irq.h>
> >  #include <linux/pci.h>
> > +#include <linux/numa_memblks.h>
> >  #include <asm/bootinfo.h>
> >  #include <asm/loongson.h>
> >  #include <asm/numa.h>
> > 
> > Could someone from the loongarch side propose the fixups needed here so
> > Yuquan can land this patch?
> 
> Hi, Dan
> 
> Should I wait for Loongarch folks's replies or draft a new patch for Loongarch
> to introduce numa_memblks according to your suggested code?

I would say go ahead and introduce the suggested changes. I think the
risk is low that copying what is done for numa_add_memblk() will break
something, and they can always jump in to fix that up if the worst case
happens.

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Mike Rapoport]

On Fri, Mar 28, 2025 at 05:21:32PM +0800, Yuquan Wang wrote:
> With numa_add_reserved_memblk(), kernel could add numa_memblk into
> numa_reserved_meminfo directly.
> 
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in suppot of future hotplug / CXL provisioning.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> ---
> 
> Changes in v2 (Thanks to Dan):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Provide a more explicit commit message
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++

For numa_memblks

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 00ac0d7bb8c9..70f1a7c6b54a 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -458,7 +458,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up
> -- 
> 2.34.1
> 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Jonathan Cameron]

On Fri, 28 Mar 2025 17:21:32 +0800
Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:

> With numa_add_reserved_memblk(), kernel could add numa_memblk into
> numa_reserved_meminfo directly.
> 
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in suppot of future hotplug / CXL provisioning.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>

Given CFMWS is a CXL thing, +cc linux-cxl

Seems like a reasonable cleanup to me.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


> ---
> 
> Changes in v2 (Thanks to Dan):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Provide a more explicit commit message
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 00ac0d7bb8c9..70f1a7c6b54a 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -458,7 +458,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Alison Schofield]

On Fri, Mar 28, 2025 at 05:21:32PM +0800, Yuquan Wang wrote:

Commit message from v1 needs updating to reflect what this v2
is doing: 'add empty CFMWS ranges to numa_reserved_meminfo"

> With numa_add_reserved_memblk(), kernel could add numa_memblk into
> numa_reserved_meminfo directly.
above comes last in commit log.

ie. State the issue like this:
> 
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in suppot of future hotplug / CXL provisioning.
'support'
> 

Then the resolution:

Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
ranges directly.


> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>

With the above commit message and log updates, and +linux-cxl mail list,
add:

Reviewed-by: Alison Schofield <alison.schofield@intel.com>

> ---
snip

Re: [PATCH v2] mm: numa_memblks: introduce numa_add_reserved_memblk

[Anshuman Khandual]

On 3/28/25 14:51, Yuquan Wang wrote:
> With numa_add_reserved_memblk(), kernel could add numa_memblk into
> numa_reserved_meminfo directly.
> 
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in suppot of future hotplug / CXL provisioning.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> ---
> 
> Changes in v2 (Thanks to Dan):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Provide a more explicit commit message
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 00ac0d7bb8c9..70f1a7c6b54a 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -458,7 +458,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up

For the NUMA memblocks

Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>