Re: [PATCH v7 1/5] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration

On 20.07.2026 18:28, Hirokazu Takahashi wrote:
> --- /dev/null
> +++ b/xen/common/cpu-topology.c
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#include <xen/acpi.h>
> +#include <xen/cpu-topology.h>
> +#include <xen/cpumask.h>
> +#include <xen/dt-cpu-topology.h>
> +#include <xen/init.h>
> +#include <xen/xvmalloc.h>
> +
> +static void __init free_topology_table(void)
> +{
> +    unsigned int cpu;
> +
> +    for ( cpu = 0; cpu < nr_cpu_ids; cpu++ )
> +    {
> +        free_cpumask_var(cpu_topology[cpu].thread_sibling);
> +        free_cpumask_var(cpu_topology[cpu].core_sibling);
> +        free_cpumask_var(cpu_topology[cpu].cluster_sibling);
> +    }
> +
> +    XVFREE(cpu_topology);
> +}
> +
> +void __init init_cpu_topology(void)
> +{
> +    unsigned int cpu;
> +    int ret;
> +
> +    cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids);
> +    if ( !cpu_topology )
> +        return;
> +
> +    for ( cpu = 0; cpu < nr_cpu_ids; cpu++ )
> +    {
> +        if ( !zalloc_cpumask_var(&cpu_topology[cpu].thread_sibling)
> +             || !zalloc_cpumask_var(&cpu_topology[cpu].core_sibling)
> +             || !zalloc_cpumask_var(&cpu_topology[cpu].cluster_sibling) )

In v6 the || here were correctly placed. Why did they move?

> --- a/xen/common/cpu.c
> +++ b/xen/common/cpu.c
> @@ -46,6 +46,10 @@ const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = {
>  #undef MASK_DECLARE_2
>  #undef MASK_DECLARE_1
>  
> +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY
> +struct cpu_topology *__ro_after_init cpu_topology;
> +#endif /* CONFIG_GENERIC_CPU_TOPOLOGY */

Looks like you also need to include xen/cpu-topology.h here. I can't see
it being included implicitly.

> --- a/xen/drivers/acpi/Kconfig
> +++ b/xen/drivers/acpi/Kconfig
> @@ -2,6 +2,9 @@
>  config ACPI
>  	bool
>  
> +config ACPI_CPU_TOPOLOGY
> +	bool
> +
>  config ACPI_LEGACY_TABLES_LOOKUP
>  	bool
>  

Did you forget to undo this change?

With all three adjustments:
Reviewed-by: Jan Beulich <[email protected]> # common, acpi

Jan