cpumask_var_t can resolve to a pointer or to an array. While the pointer
typically is allocated once for a CPU and then only read (i.e. wants to be
marked read-mostly), the same isn't necessarily true for the array case.
There things depend on how the variable is actually used. cpu_core_mask
and cpu_sibling_mask (which all architectures have inherited from x86,
which in turn is possibly wrong) are altered only as CPUs are brought up
or down, so may remain uniformly read-mostly. Other (x86-only) instances
want to change, to avoid disturbing adjacent read-mostly data.

While doing the x86 adjustment, also do one in the opposite direction,
i.e. where there was no read-mostly annotation when it is applicable in
the "pointer" case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Really in the pointer case it would be nice if the allocations could then
also come from "read-mostly" space.

--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -20,7 +20,7 @@
 static DEFINE_PER_CPU_READ_MOSTLY(u32, cpu_2_logical_apicid);
 static DEFINE_PER_CPU_READ_MOSTLY(cpumask_t *, cluster_cpus);
 static cpumask_t *cluster_cpus_spare;
-static DEFINE_PER_CPU(cpumask_var_t, scratch_mask);
+static DEFINE_PER_CPU_CPUMASK_VAR(scratch_mask);
 
 static inline u32 x2apic_cluster(unsigned int cpu)
 {
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -52,13 +52,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t
 /* representing HT and core siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
-DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, scratch_cpumask);
+DEFINE_PER_CPU_CPUMASK_VAR(scratch_cpumask);
 static cpumask_t scratch_cpu0mask;
 
-DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, hpet_scratch_cpumask);
+DEFINE_PER_CPU_CPUMASK_VAR(hpet_scratch_cpumask);
 static cpumask_t hpet_scratch_cpu0mask;
 
-DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, send_ipi_cpumask);
+DEFINE_PER_CPU_CPUMASK_VAR(send_ipi_cpumask);
 static cpumask_t send_ipi_cpu0mask;
 
 DEFINE_PER_CPU_READ_MOSTLY(struct stubs, stubs);
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -311,6 +311,9 @@ extern const cpumask_t cpumask_all;
 
 typedef cpumask_t *cpumask_var_t;
 
+#define DEFINE_PER_CPU_CPUMASK_VAR(sym) \
+	DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, sym)
+
 static inline bool alloc_cpumask_var(cpumask_var_t *mask)
 {
 	*mask = _xmalloc(nr_cpumask_bits / 8, sizeof(long));
@@ -349,6 +352,9 @@ static inline void free_cpumask_var(cpum
 #else
 typedef cpumask_t cpumask_var_t[1];
 
+#define DEFINE_PER_CPU_CPUMASK_VAR(sym) \
+	DEFINE_PER_CPU(cpumask_var_t, sym)
+
 static inline bool alloc_cpumask_var(cpumask_var_t *mask)
 {
 	return true;

On Wed, Nov 12, 2025 at 04:53:27PM +0100, Jan Beulich wrote:
> cpumask_var_t can resolve to a pointer or to an array. While the pointer
> typically is allocated once for a CPU and then only read (i.e. wants to be
> marked read-mostly), the same isn't necessarily true for the array case.
> There things depend on how the variable is actually used. cpu_core_mask
> and cpu_sibling_mask (which all architectures have inherited from x86,
> which in turn is possibly wrong) are altered only as CPUs are brought up
> or down, so may remain uniformly read-mostly. Other (x86-only) instances
> want to change, to avoid disturbing adjacent read-mostly data.
> 
> While doing the x86 adjustment, also do one in the opposite direction,
> i.e. where there was no read-mostly annotation when it is applicable in
> the "pointer" case.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> Really in the pointer case it would be nice if the allocations could then
> also come from "read-mostly" space.

Hm, I guess for some of them yes, it would make sense to come from
__read_mostly space, but would require passing an extra parameter to
the DEFINE_ helper? Or introduce another variant.

Thanks, Roger.

On 02.02.2026 16:50, Roger Pau Monné wrote:
> On Wed, Nov 12, 2025 at 04:53:27PM +0100, Jan Beulich wrote:
>> cpumask_var_t can resolve to a pointer or to an array. While the pointer
>> typically is allocated once for a CPU and then only read (i.e. wants to be
>> marked read-mostly), the same isn't necessarily true for the array case.
>> There things depend on how the variable is actually used. cpu_core_mask
>> and cpu_sibling_mask (which all architectures have inherited from x86,
>> which in turn is possibly wrong) are altered only as CPUs are brought up
>> or down, so may remain uniformly read-mostly. Other (x86-only) instances
>> want to change, to avoid disturbing adjacent read-mostly data.
>>
>> While doing the x86 adjustment, also do one in the opposite direction,
>> i.e. where there was no read-mostly annotation when it is applicable in
>> the "pointer" case.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

>> ---
>> Really in the pointer case it would be nice if the allocations could then
>> also come from "read-mostly" space.
> 
> Hm, I guess for some of them yes, it would make sense to come from
> __read_mostly space, but would require passing an extra parameter to
> the DEFINE_ helper? Or introduce another variant.

Whether this could be sorted purely at the macro wrapper layer I'm not
sure. It's the actual allocation (which alloc_cpumask_var() et al do)
which would need to be more sophisticated than a simple _x[mz]alloc().

Jan

On Mon, Feb 02, 2026 at 04:59:07PM +0100, Jan Beulich wrote:
> On 02.02.2026 16:50, Roger Pau Monné wrote:
> > On Wed, Nov 12, 2025 at 04:53:27PM +0100, Jan Beulich wrote:
> >> cpumask_var_t can resolve to a pointer or to an array. While the pointer
> >> typically is allocated once for a CPU and then only read (i.e. wants to be
> >> marked read-mostly), the same isn't necessarily true for the array case.
> >> There things depend on how the variable is actually used. cpu_core_mask
> >> and cpu_sibling_mask (which all architectures have inherited from x86,
> >> which in turn is possibly wrong) are altered only as CPUs are brought up
> >> or down, so may remain uniformly read-mostly. Other (x86-only) instances
> >> want to change, to avoid disturbing adjacent read-mostly data.
> >>
> >> While doing the x86 adjustment, also do one in the opposite direction,
> >> i.e. where there was no read-mostly annotation when it is applicable in
> >> the "pointer" case.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Thanks.
> 
> >> ---
> >> Really in the pointer case it would be nice if the allocations could then
> >> also come from "read-mostly" space.
> > 
> > Hm, I guess for some of them yes, it would make sense to come from
> > __read_mostly space, but would require passing an extra parameter to
> > the DEFINE_ helper? Or introduce another variant.
> 
> Whether this could be sorted purely at the macro wrapper layer I'm not
> sure. It's the actual allocation (which alloc_cpumask_var() et al do)
> which would need to be more sophisticated than a simple _x[mz]alloc().

For the array case it could be sorted out in the macro wrapper - for
the pointer case it would need to be sorted at allocation, which makes
this quite weird to deal with.  Anyway, this is better than nothing I
guess.

Thanks, Roger.