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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.07.2026 15:58, Hirokazu Takahashi wrote:
> I suspect that when CPU hotplug is implemented, cpu_topology[cpu].core_sibling
> And per_cpu(cpu_core_mask, cpu) will actually diverge.
> cpu_topology[cpu].core_sibling will include reserved CPUs that may be 
> hotplugged
> in the future, whereas per_cpu(cpu_sibling_mask, cpu) will only track 
> currently
> active CPUs.

I see. This then wants calling out, perhaps not only in descriptions but also
in code comments.

Jan

>>>> +/* 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.
>>
>> Thank you,
>> Hirokazu Takahashi.