> >> Also, apic_phys is (or should be) APIC_DEFAULT_PHYS_BASE, so
> >> you shouldn't need to make apic_phys global.
> >
> >Really?
> >
> > /*
> > * If no local APIC can be found then set up a fake all
> > * zeroes page to simulate the local APIC and another
> > * one for the IO-APIC.
> > */
> > if (!smp_found_config && detect_init_APIC()) {
> > apic_phys = (unsigned long) alloc_bootmem_pages(PAGE_SIZE);
> > apic_phys = __pa(apic_phys);
> > } else
> > apic_phys = mp_lapic_addr;
> >
> > set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
> >
> >So it seems to me it really is variable.
>
> The original code has the property that apic_pm_state.active is
> true if and only if detect_init_APIC() was called and succeeded,
> which implies that apic_phys == mp_lapic_addr == APIC_DEFAULT_PHYS_BASE.
> You can also see that apic_pm_resume() writes APIC_DEFAULT_PHYS_BASE
> to MSR_IA32_APICBASE, which only makes sense in this situation.
Okay, I guess I do not rely on so complicated invariants...
> You moved the apic_pm_state.active = 1 assignment from detect_init_APIC(),
> which is specific to UP_APIC, to setup_local_APIC(), which is called
> also in the SMP case. Do you intend to do suspend and resume on SMP boxes
> as well? If this is intensional, shouldn't device_apic be per-cpu?
Eventually, I do want suspend working on SMP machines, but that's
still quite a long way to go: plan is to hot-unplug all but boot CPUs,
then do suspend, then hot-plug them back.
Pavel
-- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/