> > connect_bsp_APIC();
> > - phys_cpu_present_map = 1;
> > - apic_write_around(APIC_ID, boot_cpu_physical_apicid);
> > + phys_cpu_present_map = 1 << boot_cpu_physical_apicid;
> > apic_pm_init2();
> If I'm reading this correctly, this is called out of APIC_init_uniprocessor
> from smp_init ... isn't that after people have finished using
> phys_cpu_present_map (eg setup_ioapic_ids_from_mpc)?
No, look further down in apic.c: APIC_init_uniprocessor() calls
setup_IO_APIC() which then calls setup_ioapic_ids_from_mpc(). This happens
after the code quoted above runs.
Additionally, in 2.4.x setup_local_APIC() also uses
boot_cpu_physical_apicid, although only as a sanity check. That code
is gone from (or never made it into) 2.5.
> maybe change this bit in trap_init:
> @@ -665,7 +665,6 @@
> set_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability);
> mp_lapic_addr = APIC_DEFAULT_PHYS_BASE;
> - boot_cpu_physical_apicid = 0;
> if (nmi_watchdog != NMI_NONE)
> nmi_watchdog = NMI_LOCAL_APIC;
> to do:
> boot_cpu_physical_apicid = hard_smp_processor_id();
> phys_cpu_present_map = 1 << boot_cpu_physical_apicid;
But is it necessarily true that hard_smp_processor_id() equals the APIC
Anyway, after applying Linus' patch, the first thing that touches
boot_cpu_physical_apicid becomes init_apic_mappings() which does:
if (boot_cpu_physical_apicid == -1U)
boot_cpu_physical_apicid = GET_APIC_ID(apic_read(APIC_ID));
and that's just about as good as it gets, certainly the CPU knows best
what its APIC id is.
-- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/