Re: [PATCH v1] arch_topology: Introduce nr_possible_packages

[Sudeep Holla]

On Fri, May 15, 2026 at 10:44:35PM +0800, Feng Tang wrote:
> In multi-sockets platform, kernel or driver code may need the number
> of packages for chosing different code directions. Some architecture
> already provide such kind of interface like x86, which is being used
> in some architecture code and drivers.
> 
> Add similar interface 'nr_possible_packages' for platforms which can
> get package topology information by parsing ACPI tables in boot phase,
> which was verified to show the correct number of packages on some
> 1-socket and 2-sockets production arm64 servers from different vendors.
> 

Sorry, but without a clear demonstration of how and where you plan to use
this, it is very difficult to provide meaningful feedback or review this patch
in isolation.

I am concerned that this approach may be based on another architecture, while
arm64 might have a better alternative due to how the firmware description is
structured.

Please provide more details so I can review this properly.

> Signed-off-by: Feng Tang <feng.tang@xxxxxxxxxxxxxxxxx>
> ---
> Changelog:
> 
>   since RFC:
>       * use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL (Greg)
> 	  * change the possible max package ID to 2047 (Greg)
> 	  * remove the CONFIG_ARM64/RISCV limit for 'nr_possible_packages' (Greg)
> 	
>   RFC: https://lore.kernel.org/lkml/20260512150505.43871-1-feng.tang@xxxxxxxxxxxxxxxxx/ 
> 
>  drivers/base/arch_topology.c  | 21 +++++++++++++++++++++
>  include/linux/arch_topology.h |  1 +
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index 8c5e47c28d9a..d799ba808b43 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -830,6 +830,16 @@ void remove_cpu_topology(unsigned int cpu)
>  	clear_cpu_topology(cpu);
>  }
>  
> +unsigned int nr_possible_packages __ro_after_init = 1;
> +EXPORT_SYMBOL_GPL(nr_possible_packages);
> +
> +/*
> + * Assuming silicon has a sane package ID decoding method to not have
> + * an ID bigger than 2047
> + */
> +#define MAX_PACKAGE_ID	2047
> +DECLARE_BITMAP(package_id_mask, MAX_PACKAGE_ID + 1);
> +
>  #if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
>  struct cpu_smt_info {
>  	unsigned int thread_num;
> @@ -912,6 +922,13 @@ __weak int __init parse_acpi_topology(void)
>  		cpu_topology[cpu].cluster_id = topology_id;
>  		topology_id = find_acpi_cpu_topology_package(cpu);
>  		cpu_topology[cpu].package_id = topology_id;
> +
> +
> +		if (topology_id >= 0 && topology_id <= MAX_PACKAGE_ID)
> +			bitmap_set(package_id_mask, topology_id, 1);
> +		else
> +			pr_warn("ACPI: abnormal package ID: %d !\n",
> +				topology_id);
>  	}
>

MAX_PACKAGE_ID is set to 2047 yet it reads from PPTT which has no such
restriction. So it completely falls apart there as UID is just 32-bit
number IIUC. If UID is not present we compute offset which is sparse
and even that can be > 2047.

>  	/*
> @@ -927,6 +944,10 @@ __weak int __init parse_acpi_topology(void)
>  
>  	cpu_smt_set_num_threads(max_smt_thread_num, max_smt_thread_num);
>  	xa_destroy(&hetero_cpu);
> +
> +	/* Count the number of possible packages in system */
> +	nr_possible_packages = bitmap_weight(package_id_mask, MAX_PACKAGE_ID + 1);
> +	pr_info("ACPI: System has %u package(s) detected\n", nr_possible_packages);
>  	return 0;
>  }

IIUC x86 does not expose raw firmware package IDs as an array bound.  It builds
topology domain bitmaps and derives dense logical package IDs from them.

>  
> diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> index ebd7f8935f96..960045e6ac05 100644
> --- a/include/linux/arch_topology.h
> +++ b/include/linux/arch_topology.h
> @@ -105,6 +105,7 @@ static inline bool topology_core_has_smt(int cpu)
>  	return cpu_topology[cpu].thread_id != -1;
>  }
>  
> +extern unsigned int nr_possible_packages;

It does not provide a logical package ID mapping corresponding to the count.
A consumer that uses nr_possible_packages for allocation and
topology_physical_package_id(cpu) for indexing can still index out of bounds
on sparse ACPI Processor IDs or on PPTT offset-based IDs.

-- 
Regards,
Sudeep