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

Hello,

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.

> > > +/* 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.