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

On 19.07.2026 03:17, Hirokazu Takahashi wrote:
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +
>>> +#ifndef XEN_CPU_TOPOLOGY_H
>>> +#define XEN_CPU_TOPOLOGY_H
>>> +
>>> +#include <xen/cpumask.h>
>>> +
>>> +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY
>>> +
>>> +struct cpu_topology {
>>> +    cpumask_var_t thread_sibling;
>>
>> Btw, as this aspect becomes more apparent when looking at patch 2: What is the
>> relationship of this (i.e. cpu_topology[cpu].thread_sibling) to
>> per_cpu(cpu_sibling_mask, cpu)? The two ought to be identical, but I can't see
>> this being guaranteed. And if they were identical, why would both be needed?
>>
>>> +    cpumask_var_t core_sibling;
>>
>> Same for this vs the per-CPU cpu_core_mask.
> 
> I have considered the same thing before. However, considering the CPU hotplug
> support that Mykyta Poturai is currently implementing, it is difficult to remove
> thread_sibling and core_sibling from struct cpu_topology. We intend to use 
> cpu_topology to hold information for CPUs that haven't been hotplugged yet.
> 
> While it might make more sense to remove the per-CPU masks instead, 
> I hesitated to do so because the impact on x86 Xen would be quite large.

That's understood, but imo removing the duplication should still be a follow-on
work item, if it can't reasonably be done right here. And the duplication then
imo wants an extra word of justification in the patch(es) introducing it.

Jan