Hello, Thanks for the review.
> I am the original writer of this code. In the original code, the list > reserve capacity for the max number of cpus (265, max allowed by xAPIC) and, > once we know how many cpus are really in the machine, then reduce the > capacity store this amount. The list is allocated in apic_data_init() as kalloc(NCPUS * sizeof(uint16_t)). NCPUS is the --enable-ncpus value (configfrag-first.ac), so it is the CPU capacity of that build, not the 256 xAPIC IDs; those are the separate cpu_id_lut array. With --enable-ncpus=4 the list holds four entries. Reserving the 256 APIC IDs instead would not remove the NCPUS limit: the other per-CPU arrays (percpu_array, mp_desc_table, ...) are NCPUS entries, so the parser must stop at NCPUS anyway. > By this reason we don't check the capacity: it's already the maximum > allowed by the standard. apic_add_cpu() has no check of its own; the parser guarded the call. The patch puts the bound in apic_add_cpu() and keeps the allocated size in capacity, so it also follows apic_refit_cpulist(), which shrinks the list to the accepted count. > The APIC ID never can be over than 255 (the APIC ID use 8 bits) Thanks, removed that check. David
