x86, apic: Map the local apic when parsing the MP table.
in [Kernel]
|
Prev: [ANNOUNCE] BFS CPU scheduler v0.323 for 2.6.35
Next: [PATCH 1/4] perf probe: Fix to copy the type for raw parameters
From: Eric W. Biederman on 6 Aug 2010 21:10 "H. Peter Anvin" <hpa(a)zytor.com> writes: > On 08/06/2010 05:08 PM, Yinghai Lu wrote: >> this change is not needed, it will break: >> 1. found mptable, but is using default contruct path. >> 2. visws path, found found mptable, but get_smp_conf is not called. >> >> YH > > I'm not sure the above is decipherable. Please provide an incremental > patch with a more detailed description. YH was saying I overoptimized, and it looks like he is right, although there are only one or two machines in existence that are likely to be affected. Untested patch to remove the cleverness below. It it boots all is well. --- From: Eric W. Biederman <ebiederm(a)xmission.com> Date: Fri, 6 Aug 2010 18:00:12 -0700 Subject: [PATCH] x86/apic: Always map the local apic in init_apic_mappings. In all of the common cases we currently map the local apic before we get to init_apic_mappings. Unfortunately there are still a few weird subarch code paths that require us to map the local apic in init_apic_mappings, and those subarchitectures set smp_found_config. So just unconditionally run the fixmap code, and stop being clever. Signed-off-by: Eric W. Biederman <ebiederm(a)xmission.com> --- arch/x86/kernel/apic/apic.c | 13 +++++++++---- 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index c07e513..ad96090 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1603,11 +1603,16 @@ void __init init_apic_mappings(void) apic_phys = mp_lapic_addr; /* - * acpi lapic path already maps that address in - * acpi_register_lapic_address() + * acpi and mptable paths already fixmap mp_lapic_addr + * at FIX_APIC_BASE but perform the fixmap anyway + * because our initialization code is spaghetti and + * there are weird subarchitectures that do something + * different. The double fixmap isn't particularly + * expensive and always running the code should prevent + * bitrot. + * */ - if (!acpi_lapic && !smp_found_config) - set_fixmap_nocache(FIX_APIC_BASE, apic_phys); + set_fixmap_nocache(FIX_APIC_BASE, apic_phys); apic_printk(APIC_VERBOSE, "mapped APIC to %08lx (%08lx)\n", APIC_BASE, apic_phys); -- 1.6.5.2.143.g8cc62 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 6 Aug 2010 22:50
Yinghai Lu <yinghai(a)kernel.org> writes: > On 08/06/2010 06:21 PM, H. Peter Anvin wrote: >> On 08/06/2010 06:08 PM, Eric W. Biederman wrote: >>>> >>>> I'm not sure the above is decipherable. Please provide an incremental >>>> patch with a more detailed description. >>> >>> YH was saying I overoptimized, and it looks like he is right, >>> although there are only one or two machines in existence that >>> are likely to be affected. >>> >>> Untested patch to remove the cleverness below. It it boots all >>> is well. >>> >> >> This makes sense to me. Yinghai, do you have a system that is actually >> affected, and if so, could you test this patch? > > no, i don't have those kind of system. I don't know if anyone does. It looks like sfi aka moorestown and visws are what are affected. That is why I made a patch that any boot where we exercise a local apic will exercise. Arguably if it is best to just remove that hunk from my patch, so we have something that is safe to backport to 2.6.35.1. > found it when i was preparing more smp_register_lapic_address patcheset. > > I suggest we still keep !acpi_lapic checking, that should always right. Ultimately we want to remove the code duplication entirely. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |