On Thu, Jun 01, 2017 at 12:53:28PM +0200, Igor Mammedov wrote: > Calculating default node-ids for CPUs in possible_cpu_arch_ids() > is rather fragile since defaults calculation uses nb_numa_nodes but > callback might be potentially called early before all -numa CLI > options are parsed, which would lead to cpus assigned only upto > nb_numa_nodes at the time possible_cpu_arch_ids() is called. > > Issue was introduced by > (7c88e65 numa: mirror cpu to node mapping in MachineState::possible_cpus) > and for example CLI: > -smp 4 -numa node,cpus=0 -numa node > would set props.node-id in possible_cpus array for every non > explicitly mapped CPU to the first node. > > Issue is not visible to guest nor to mgmt interface due to > 1) implictly mapped cpus are forced to the first node in > case of partial mapping > 2) in case of default mapping possible_cpu_arch_ids() is > called after all -numa options are parsed (resulting > in correct mapping). > > However it's fragile to rely on late execution of > possible_cpu_arch_ids(), therefore add machine specific > callback that returns node-id for CPU and use it to calculate/ > set defaults at machine_numa_finish_init() time when all -numa > options are parsed. > > Reported-by: Eduardo Habkost <ehabk...@redhat.com> > Signed-off-by: Igor Mammedov <imamm...@redhat.com>
Reviewed-by: Eduardo Habkost <ehabk...@redhat.com> Queued on numa-next. Thanks! -- Eduardo
