Re: [PATCH v2 for-4.21 3/9] x86/HPET: replace handle_hpet_broadcast()'s on-stack cpumask_t

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.10.2025 16:08, Roger Pau Monné wrote:
> On Mon, Oct 20, 2025 at 01:19:20PM +0200, Jan Beulich wrote:
>> With large NR_CPUS on-stack cpumask_t variables are problematic. Now that
>> the IRQ handler can't be invoked in a nested manner anymore, we can
>> instead use a per-CPU variable. While we can't use scratch_cpumask in code
>> invoked from IRQ handlers, simply amend that one with a HPET-special form.
>> (Note that only one of the two IRQ handling functions can come into play
>> at any one time.)
>>
>> Fixes: 996576b965cc ("xen: allow up to 16383 cpus")
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks.

>> --- a/xen/arch/x86/include/asm/smp.h
>> +++ b/xen/arch/x86/include/asm/smp.h
>> @@ -22,6 +22,7 @@
>>  DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
>>  DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
>>  DECLARE_PER_CPU(cpumask_var_t, scratch_cpumask);
>> +DECLARE_PER_CPU(cpumask_var_t, hpet_scratch_cpumask);
> 
> Should this be declared in the hpet.h header?

Imo not without also ...

>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -55,6 +55,9 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t
>>  DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, scratch_cpumask);
>>  static cpumask_t scratch_cpu0mask;
>>  
>> +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, hpet_scratch_cpumask);
>> +static cpumask_t hpet_scratch_cpu0mask;
> 
> And then this defined in hpet.c.

... moving this. Which in turn I specifically avoided putting in hpet.c,
as otherwise the change would further grow, as would the risk of things
going out of sync.

Jan