Re: [PATCH] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/1/26 5:59 PM, Jan Beulich wrote:
> On 01.09.2026 17:50, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/imsic.c
> > +++ b/xen/arch/riscv/imsic.c
> > @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node)
> >       unsigned int nr_parent_irqs, index, nr_handlers = 0;
> >       paddr_t base_addr;
> >       unsigned int nr_mmios;
> > +    /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */
> > +    unsigned int nr_msi = num_possible_cpus();
> The possible-CPUs-map may be sparse, so num_possible_cpus() may still yield
> too small a value to use here. The thing to use likely is nr_cpu_ids. I notice
> that variable is entirely unused so far by arch/riscv/*, though.
IIUC "sparse" means we could have three CPUs with IDs 0, 1 and 12, so 
bits 0, 1 and 12 would be set in cpu_possible_map.
In that case num_possible_cpus() returns 3, which is the correct 
*number* of CPUs but msi[] is indexed by the Xen CPU ID, not by the 
CPU's ordinal position in the mask, so indexing it with ID 12 would need 
13 entries. The two only coincide when the mask is dense, so you are 
right that num_possible_cpus() is the wrong bound in principle.
That said, cpu_possible_map shouldn't be sparse by construction: the 
boot CPU is assigned ID 0 in smp_prepare_boot_cpu(), and the remaining 
IDs are handed out sequentially, so the bits are always 0..N-1 (for 
RISC-V it is done in such way in downstream). Arm, the other user of 
cpu_possible_map, fills it with Xen CPU IDs the same way.
I agree it is better not to depend on that, so I will use nr_cpu_ids for 
nr_msi instead.
~ Oleksii