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
