On 11/10/2016 01:50 PM, Charles (Chas) Williams wrote: > > > On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote: >> [ 0.002000] mvb: CPU: Physical Processor ID: 0 >> [ 0.002000] mvb: CPU: Processor Core ID: 0 >> [ 0.002000] mvb: identify_cpu:1112: c: ffff880013b0a040, >> c->logical_proc_id: 65535 >> [ 0.002000] mvb: __default_cpu_present_to_apicid:612: Returning >> 65535! mps_cpu: 1, nr_cpu_ids: 2, cpu_present(mps_cpu): 1 >> [ 0.002000] smpboot: mvb: topology_update_package_map:270: cpu: 1, >> pkg: 4095 >> [ 0.002000] smpboot: APIC(ffff) Converting physical 4095 to logical >> package 0 >> [ 0.002000] smpboot: mvb: topology_update_package_map:305: cpu: 1, >> cpu_data(cpu).logical_proc_id: 0 > > This seems strange. 0xffff is BAD_APICID. Why didn't this fail here: > > for_each_present_cpu(cpu) { > unsigned int apicid = apic->cpu_present_to_apicid(cpu); > > if (apicid == BAD_APICID || > !apic->apic_id_valid(apicid)) <<<<<<<<<< > continue; > if (!topology_update_package_map(apicid, cpu)) > continue; > > topology_update_package_map() should never have been called?
(Sorry for the delay!) It appears that this is a different call path than the one in smp_init_package_map function. I *think* the following call path is the one shown in the dmesg, but I am not sure: cpu_bringup_and_idle cpu_bringup (arch/x86/xen/smp.c) smp_store_cpu_info (this call path branch is included for context) identify_secondary_cpu identify_cpu detect_ht topology_update_package_map Sorry about the potentially misleading dmesg excerpt I posted. Vefa