On Fri, Feb 05, 2016 at 05:44:49PM +0100, Igor Mammedov wrote: > On Fri, 5 Feb 2016 17:19:50 +0100 > Igor Mammedov <imamm...@redhat.com> wrote: > > > On Fri, 5 Feb 2016 13:39:07 -0200 > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > On Thu, Feb 04, 2016 at 12:47:33PM +0100, Igor Mammedov wrote: > > > > cpu->found_cpus bitmap is used for setting present > > > > flag in CPON AML package at start up. But it takes > > > > a bunch of code to fill bitmap and cloud be simplified > > > > by calling qemu_get_cpu_by_arch_id(apic_id) directly. > > > > > > > > Hence do so and remove not used anymore bitmap > > > > with related utilities, which saves us ~32LOC > > > > and also would simplify consolidating APCI parts > > > > of CPU hotplug. > > > > > > > > Signed-off-by: Igor Mammedov <imamm...@redhat.com> > > > > > > This makes the code loops through all smp_cpus CPUs max_cpus > > > times, instead of just looping through the smp_cpus CPUs once. > > Yep, that looks bad. > > I'll redo it using possible_cpu_arch_ids(), it is a little > > bit bigger refactoring. > I think I'll make bitmap local to build_processor_devices() as it's > needed only for building CPON package, that way it will go along > with related legacy hotplug and won't get in the way of new hotplug.
What about pc_possible_cpu_arch_ids() itself? It has exactly the same problem: it looks at CPU objects smp_cpus*max_cpus times, to fill the CPUArchId.cpu field. If that's a problem for build_processor_devices(), I assume that's a problem for all other possible_cpu_arch_ids() callers? -- Eduardo
