aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/kernel/apic_64.c
AgeCommit message (Collapse)Author
2008-07-26x86: apic_*.c: add description to AMD's extended LVT functionsRobert Richter
Signed-off-by: Robert Richter <robert.richter@amd.com> Cc: oprofile-list <oprofile-list@lists.sourceforge.net> Cc: Barry Kasindorf <barry.kasindorf@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-24x86: apic unification - merge down enable_NMI_through_LVT0Cyrill Gorcunov
No code change on binary level. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: macro@linux-mips.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-24x86: apic unification - merge down lapic_get_maxlvtCyrill Gorcunov
No code change on binary level. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: macro@linux-mips.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-22Merge branch 'linus' into x86/x2apicIngo Molnar
2008-07-21Merge branches 'x86/urgent', 'x86/amd-iommu', 'x86/apic', 'x86/cleanups', ↵Ingo Molnar
'x86/core', 'x86/cpu', 'x86/fixmap', 'x86/gart', 'x86/kprobes', 'x86/memtest', 'x86/modules', 'x86/nmi', 'x86/pat', 'x86/reboot', 'x86/setup', 'x86/step', 'x86/unify-pci', 'x86/uv', 'x86/xen' and 'xen-64bit' into x86/for-linus
2008-07-21x86: use setup_clear_cpu_cap() when disabling the lapicYinghai Lu
... so don't need to call clear_cpu_cap again in early_identify_cpu, and could use cleared_cpu_caps like other places. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-19x86: APIC: Remove apic_write_around(); use alternatives, merge fixSuresh Siddha
On Fri, Jul 18, 2008 at 02:03:48PM -0700, Ingo Molnar wrote: > > * Yinghai Lu <yhlu.kernel@gmail.com> wrote: > > > > git merge tip/x86/x2apic > > CONFLICT (content): Merge conflict in arch/x86/kernel/Makefile > > CONFLICT (content): Merge conflict in arch/x86/kernel/paravirt.c > > CONFLICT (content): Merge conflict in arch/x86/kernel/smpboot.c > > CONFLICT (content): Merge conflict in arch/x86/kernel/vmi_32.c > > CONFLICT (content): Merge conflict in arch/x86/xen/enlighten.c > > CONFLICT (content): Merge conflict in include/asm-x86/apic.h > > CONFLICT (content): Merge conflict in include/asm-x86/paravirt.h > > that's due to the changes in tip/x86/apic and in tip/x86/uv. > > ok, i've just merged x86/apic into x86/x2apic and x86/uv as well, and > pushed out the result. > > Note: it's a first raw merge and completely untested. It will now merge > cleanly into tip/master. There are probably a few details missing. Ingo, thanks for doing this. While I was testing my merge changes, you posted yours... anyhow we need this piece, which is missing from your merge. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Zachary Amsden <zach@vmware.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-18Merge branch 'x86/apic' into x86/x2apicIngo Molnar
Conflicts: arch/x86/kernel/paravirt.c arch/x86/kernel/smpboot.c arch/x86/kernel/vmi_32.c arch/x86/lguest/boot.c arch/x86/xen/enlighten.c include/asm-x86/apic.h include/asm-x86/paravirt.h Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-18x86: APIC: Make apic_verbosity unsignedMaciej W. Rozycki
As a microoptimisation, make apic_verbosity unsigned. This will make apic_printk(APIC_QUIET, ...) expand into just printk(...) with the surrounding condition and a reference to apic_verbosity removed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-18x86: apic_64 - make calibrate_APIC_clock to return error codeCyrill Gorcunov
Make calibration_result to return error and check calibration_result to be sufficient inside calibrate_APIC_clock. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Cc: macro@linux-mips.org Cc: yhlu.kernel@gmail.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x86: make read_apic_id return final apicidYinghai Lu
also remove GET_APIC_ID when read_apic_id is used. need to apply after [PATCH] x86: mach_apicdef.h need to include before smp.h Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x64, x2apic/intr-remap: add x2apic support, including enabling ↵Suresh Siddha
interrupt-remapping x2apic support. Interrupt-remapping must be enabled before enabling x2apic, this is needed to ensure that IO interrupts continue to work properly after the cpu mode is changed to x2apic(which uses 32bit extended physical/cluster apic id). On systems where apicid's are > 255, BIOS can handover the control to OS in x2apic mode. Or if the OS handover was in legacy xapic mode, check if it is capable of x2apic mode. And if we succeed in enabling Interrupt-remapping, then we can enable x2apic mode in the CPU. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: akpm@linux-foundation.org Cc: arjan@linux.intel.com Cc: andi@firstfloor.org Cc: ebiederm@xmission.com Cc: jbarnes@virtuousgeek.org Cc: steiner@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x64, x2apic/intr-remap: IO-APIC support for interrupt-remappingSuresh Siddha
IO-APIC support in the presence of interrupt-remapping infrastructure. IO-APIC RTE will be programmed with interrupt-remapping table entry(IRTE) index and the IRTE will contain information about the vector, cpu destination, trigger mode etc, which traditionally was present in the IO-APIC RTE. Introduce a new irq_chip for cleaner irq migration (in the process context as opposed to the current irq migration in the context of an interrupt. interrupt-remapping infrastructure will help us achieve this cleanly). For edge triggered, irq migration is a simple atomic update(of vector and cpu destination) of IRTE and flush the hardware cache. For level triggered, we need to modify the io-apic RTE aswell with the update vector information, along with modifying IRTE with vector and cpu destination. So irq migration for level triggered is little bit more complex compared to edge triggered migration. But the good news is, we use the same algorithm for level triggered migration as we have today, only difference being, we now initiate the irq migration from process context instead of the interrupt context. In future, when we do a directed EOI (combined with cpu EOI broadcast suppression) to the IO-APIC, level triggered irq migration will also be as simple as edge triggered migration and we can do the irq migration with a simple atomic update to IO-APIC RTE. TBD: some tests/changes needed in the presence of fixup_irqs() for level triggered irq migration. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: akpm@linux-foundation.org Cc: arjan@linux.intel.com Cc: andi@firstfloor.org Cc: ebiederm@xmission.com Cc: jbarnes@virtuousgeek.org Cc: steiner@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x64, x2apic/intr-remap: x2apic ops for x2apic mode supportSuresh Siddha
x2apic ops for x2apic mode support. This uses MSR interface and differs slightly from the xapic register layout. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: akpm@linux-foundation.org Cc: arjan@linux.intel.com Cc: andi@firstfloor.org Cc: ebiederm@xmission.com Cc: jbarnes@virtuousgeek.org Cc: steiner@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x64, x2apic/intr-remap: basic apic ops supportSuresh Siddha
Introduce basic apic operations which handle the apic programming. This will be used later to introduce another specific operations for x2apic. For the perfomance critial accesses like IPI's, EOI etc, we use the native operations as they are already referenced by different indirections like genapic, irq_chip etc. 64bit Paravirt ops can also define their apic operations accordingly. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: akpm@linux-foundation.org Cc: arjan@linux.intel.com Cc: andi@firstfloor.org Cc: ebiederm@xmission.com Cc: jbarnes@virtuousgeek.org Cc: steiner@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x64, x2apic/intr-remap: Interrupt-remapping and x2apic support, fixSuresh Siddha
Yinghai Lu wrote: > Setting APIC routing to physical flat > Kernel panic - not syncing: Boot APIC ID in local APIC unexpected (0 vs 4) > Pid: 1, comm: swapper Not tainted 2.6.26-rc9-tip-01763-g74f94b1-dirty #320 > > Call Trace: > [<ffffffff80a21505>] ? set_cpu_sibling_map+0x38c/0x3bd > [<ffffffff80245215>] ? read_xapic_id+0x25/0x3e > [<ffffffff80e5a2c3>] ? verify_local_APIC+0x139/0x1b9 > [<ffffffff80245215>] ? read_xapic_id+0x25/0x3e > [<ffffffff80e589af>] ? native_smp_prepare_cpus+0x224/0x2e9 > [<ffffffff80e4881a>] ? kernel_init+0x64/0x341 > [<ffffffff8022a439>] ? child_rip+0xa/0x11 > [<ffffffff80e487b6>] ? kernel_init+0x0/0x341 > [<ffffffff8022a42f>] ? child_rip+0x0/0x11 > > > guess read_apic_id changing cuase some problem... genapic's read_apic_id() returns the actual apic id extracted from the APIC_ID register. And in some cases like UV, read_apic_id() returns completely different values from APIC ID register. Use the native apic register read, rather than genapic read_apic_id() in verify_local_APIC() And also, lapic_suspend() should also use native apic register read. Reported-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org> Cc: "arjan@linux.intel.com" <arjan@linux.intel.com> Cc: "andi@firstfloor.org" <andi@firstfloor.org> Cc: "ebiederm@xmission.com" <ebiederm@xmission.com> Cc: "jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org> Cc: "steiner@sgi.com" <steiner@sgi.com> Cc: "jeremy@goop.org" <jeremy@goop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-12x64, x2apic/intr-remap: introduce read_apic_id() to genapic routinesSuresh Siddha
Move the read_apic_id() to genapic routines. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: akpm@linux-foundation.org Cc: arjan@linux.intel.com Cc: andi@firstfloor.org Cc: ebiederm@xmission.com Cc: jbarnes@virtuousgeek.org Cc: steiner@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: nmi_watchdog - use NMI_NONE by defaultCyrill Gorcunov
There is no need to keep NMI_DISABLED definition and use it for nmi_watchdog by default. Here is the point why: - IO-APIC and APIC chips are programmed for nmi_watchdog support at very early stage of kernel booting and not having nmi_watchdog specified as boot option lead only to nmi_watchdog becomes to NMI_NONE anyway - enable nmi_watchdog thru /proc/sys/kernel/nmi if it was not specified at boot is not possible too (even having this sysfs entry) Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: macro@linux-mips.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: nmi_watchdog - use nmi_watchdog variable for printingCyrill Gorcunov
Since it is possible NMI_ definitions could be changed one day we better print out real nmi_watchdog value instead of constant string. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: macro@linux-mips.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: provide connect_bsp_APIC for x86_64Glauber Costa
Although it is not really needed, we provide it to get closer to i386. ifdefs around it are removed in smpboot.c Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Merge branch 'x86/uv' into x86/develIngo Molnar
2008-07-08x86: fix stack overflow for large values of MAX_APICSJack Steiner
physid_mask_of_physid() causes a huge stack (12k) to be created if the number of APICS is large. Replace physid_mask_of_physid() with a new function that does not create large stacks. This is a problem only on large x86_64 systems. this paves the way to increase MAX_APICS. Signed-off-by: Jack Steiner <steiner@sgi.com> Cc: linux-mm@kvack.org Cc: mingo@elte.hu Cc: tglx@linutronix.de Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Merge branch 'x86/numa' into x86/develIngo Molnar
Conflicts: arch/x86/Kconfig arch/x86/kernel/e820.c arch/x86/kernel/efi_64.c arch/x86/kernel/mpparse.c arch/x86/kernel/setup.c arch/x86/kernel/setup_32.c arch/x86/mm/init_64.c include/asm-x86/proto.h Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: cleanup early per cpu variables/accesses v4Mike Travis
* Introduce a new PER_CPU macro called "EARLY_PER_CPU". This is used by some per_cpu variables that are initialized and accessed before there are per_cpu areas allocated. ["Early" in respect to per_cpu variables is "earlier than the per_cpu areas have been setup".] This patchset adds these new macros: DEFINE_EARLY_PER_CPU(_type, _name, _initvalue) EXPORT_EARLY_PER_CPU_SYMBOL(_name) DECLARE_EARLY_PER_CPU(_type, _name) early_per_cpu_ptr(_name) early_per_cpu_map(_name, _idx) early_per_cpu(_name, _cpu) The DEFINE macro defines the per_cpu variable as well as the early map and pointer. It also initializes the per_cpu variable and map elements to "_initvalue". The early_* macros provide access to the initial map (usually setup during system init) and the early pointer. This pointer is initialized to point to the early map but is then NULL'ed when the actual per_cpu areas are setup. After that the per_cpu variable is the correct access to the variable. The early_per_cpu() macro is not very efficient but does show how to access the variable if you have a function that can be called both "early" and "late". It tests the early ptr to be NULL, and if not then it's still valid. Otherwise, the per_cpu variable is used instead: #define early_per_cpu(_name, _cpu) \ (early_per_cpu_ptr(_name) ? \ early_per_cpu_ptr(_name)[_cpu] : \ per_cpu(_name, _cpu)) A better method is to actually check the pointer manually. In the case below, numa_set_node can be called both "early" and "late": void __cpuinit numa_set_node(int cpu, int node) { int *cpu_to_node_map = early_per_cpu_ptr(x86_cpu_to_node_map); if (cpu_to_node_map) cpu_to_node_map[cpu] = node; else per_cpu(x86_cpu_to_node_map, cpu) = node; } * Add a flag "arch_provides_topology_pointers" that indicates pointers to topology cpumask_t maps are available. Otherwise, use the function returning the cpumask_t value. This is useful if cpumask_t set size is very large to avoid copying data on to/off of the stack. * The coverage of CONFIG_DEBUG_PER_CPU_MAPS has been increased while the non-debug case has been optimized a bit. * Remove an unreferenced compiler warning in drivers/base/topology.c * Clean up #ifdef in setup.c For inclusion into sched-devel/latest tree. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-07-08Merge branch 'x86/mpparse' into x86/develIngo Molnar
Conflicts: arch/x86/Kconfig arch/x86/kernel/io_apic_32.c arch/x86/kernel/setup_64.c arch/x86/mm/init_32.c Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Merge branch 'linus' into tmp.x86.mpparse.newIngo Molnar
2008-07-08Merge branches 'x86/numa-fixes', 'x86/apic', 'x86/apm', 'x86/bitops', ↵Ingo Molnar
'x86/build', 'x86/cleanups', 'x86/cpa', 'x86/cpu', 'x86/defconfig', 'x86/gart', 'x86/i8259', 'x86/intel', 'x86/irqstats', 'x86/kconfig', 'x86/ldt', 'x86/mce', 'x86/memtest', 'x86/pat', 'x86/ptemask', 'x86/resumetrace', 'x86/threadinfo', 'x86/timers', 'x86/vdso' and 'x86/xen' into x86/devel
2008-07-08x86: APIC/UP: Downgrade the NMI watchdog for no I/O APICMaciej W. Rozycki
If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip will not be used in the UP configuration, because "noapic" has been specified or the chip is simply not there. Downgrade to the local APIC watchdog to rectify. The new #ifdef is ugly, I know. A proper solution is to provide suitable definitions of smp_found_config, etc. for !CONFIG_X86_IO_APIC in a header. Likewise the whole if () condition should be moved to a static inline function. Such clean-ups are beyond the scope of this change and can be done once the whole issue of the timer has been sorted out. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Revert "x86, io-apic: fix nmi_watchdog=1 bootup hang"Ingo Molnar
This reverts commit 2229ff84f01746d02fb6b79e156fb5cce48c908f. A better fix from Maciej will be merged.
2008-07-08x86, io-apic: fix nmi_watchdog=1 bootup hangIngo Molnar
nmi_watchdog=1 hangs on 64-bit: [ 0.250000] Detected 12.564 MHz APIC timer. [ 0.254178] APIC timer registered as dummy, due to nmi_watchdog=1! [ 0.260366] Testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears to be stuck (0->0)! [ ... ] [ 0.470003] calling genl_init+0x0/0xd0 [ hard hang ] bisected it down to: git-bisect start git-bisect good 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 git-bisect bad 11582ece0aaa2d0f94f345c08a4ab9997078a083 git-bisect bad 5479c623bb44089844022c03d4c0eb16d5b7a15f git-bisect bad cfb4c7fabeb499e1c29f9d1878968e37a938e28a git-bisect good 246dd412d31e4f5de1d43aa6422a325b785f36e4 git-bisect bad 3f8237eaff7dc1e35fa791dae095574fd974e671 git-bisect good 90e23b13ab849e2a11f00c655eb3a2011b4623be git-bisect bad 833526a34eeefc117df3191a594c3c3a4f15a9ac git-bisect good 791b93d3dfaf16c23e978bec0cc0a3dd9d855d63 git-bisect bad 65767c64068f2c93e56a1accfed5c78230ac12d7 git-bisect bad 2abc5c05dd82c188e3bdf6641a274f013348d14b git-bisect bad 317e1f2597ffb4d4db940577bbe56dc6e881ef07 | 317e1f2597ffb4d4db940577bbe56dc6e881ef07 is first bad commit | commit 317e1f2597ffb4d4db940577bbe56dc6e881ef07 | Author: Maciej W. Rozycki <macro@linux-mips.org> | Date: Wed May 21 22:10:22 2008 +0100 | x86: I/O APIC: clean up the 8259A on a NMI watchdog failure the problem is that in the dummy-lapic branch we rely on the i8259A but if the NMI watchdog fails we turn off IRQ 0 - which doesnt work too well ;-) Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: apic_64.c fix sparse warnings about shadowed variablesThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86, clockevents: add C1E aware idle functionThomas Gleixner
C1E on AMD machines is like C3 but without control from the OS. Up to now we disabled the local apic timer for those machines as it stops when the CPU goes into C1E. This excludes those machines from high resolution timers / dynamic ticks, which hurts especially X2 based laptops. The current boot time C1E detection has another, more serious flaw as well: some BIOSes do not enable C1E until the ACPI processor module is loaded. This causes systems to stop working after that point. To work nicely with C1E enabled machines we use a separate idle function, which checks on idle entry whether C1E was enabled in the Interrupt Pending Message MSR. This allows us to do timer broadcasting for C1E and covers the late enablement of C1E as well. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-10x86: introduce max_physical_apicid for bigsmp switchingYinghai Lu
a multi-socket test-system with 3 or 4 ioapics, when 4 dualcore cpus or 2 quadcore cpus installed, needs to switch to bigsmp or physflat. CPU apic id is [4,11] instead of [0,7], and we need to check max apic id instead of cpu numbers. also add check for 32 bit when acpi is not compiled in or acpi=off. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-25x86: move smp_found_configAlexey Starikovskiy
2008-05-23x86: don't read maxlvt before checking if APIC is mappedChuck Ebbert
A check for unmapped apic was added before reading maxlvt but the early read of maxlvt wasn't removed. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org
2008-04-26x86: cleanup div_sc() usageAkinobu Mita
Remove the magic number in the third argment of div_sc(). Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-24"make namespacecheck" fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move up & smp variables to setup.cAlexey Starikovskiy
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move x86_bios_cpu_apicid to io_apic_64.cAlexey Starikovskiy
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: support for new UV apicJack Steiner
UV supports really big systems. So big, in fact, that the APICID register does not contain enough bits to contain an APICID that is unique across all cpus. The UV BIOS supports 3 APICID modes: - legacy mode. This mode uses the old APIC mode where APICID is in bits [31:24] of the APICID register. - x2apic mode. This mode is whitebox-compatible. APICIDs are unique across all cpus. Standard x2apic APIC operations (Intel-defined) can be used for IPIs. The node identifier fits within the Intel-defined portion of the APICID register. - x2apic-uv mode. In this mode, the APICIDs on each node have unique IDs, but IDs on different node are not unique. For example, if each mode has 32 cpus, the APICIDs on each node might be 0 - 31. Every node has the same set of IDs. The UV hub is used to route IPIs/interrupts to the correct node. Traditional APIC operations WILL NOT WORK. In x2apic-uv mode, the ACPI tables all contain a full unique ID (note: exact bit layout still changing but the following is close): nnnnnnnnnnlc0cch n = unique node number l = socket number on board c = core h = hyperthread Only the "lc0cch" bits are written to the APICID register. The remaining bits are supplied by having the get_apic_id() function "OR" the extra bits into the value read from the APICID register. (Hmmm.. why not keep the ENTIRE APICID register in per-cpu data....) The x2apic-uv mode is recognized by the MADT table containing: oem_id = "SGI" oem_table_id = "UV-X" Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: change GET_APIC_ID() from an inline function to an out-of-line functionJack Steiner
Introduce a function to read the local APIC_ID. This change is in preparation for additional changes to the APICID functions that will come in a later patch. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move generic_processor_info to apic_64.cAlexey Starikovskiy
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move boot_cpu_physical_apicid to apic_64.cAlexey Starikovskiy
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move mp_lapic_addr to apic_64.cAlexey Starikovskiy
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move apic declarations to mach_apic.hGlauber Costa
take them out of the x86_64-specific asm/mach_apic.h Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: move ipi definitions to mach_ipi.hGlauber Costa
take them out of the x86_64-only asm/mach_apic.h Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: apic_is_clustered_box to indicate unsynched TSC's on multiboard vSMP ↵Ravikiran G Thirumalai
systems Indicate TSCs are unreliable as time sources if the platform is a multi chassi ScaleMP vSMPowered machine. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: change boot_cpu_id to boot_cpu_physical_apicidGlauber de Oliveira Costa
This is to match i386. The former name was cuter, but the current is more meaningful and more general, since cpu_id can be a logical id. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: get boot_cpu_id as early for k8_scan_nodesYinghai Lu
When acpi=off or there is no SRAT defined, apicid_to_node is got from K8 Northbridge PCI configuration space in k8_scan_nodes() in arch/x86_64/mm/k8toplogy.c. The problem is that it assumes bsp apic id is 0 at that point. For four socket system with Quad core cpus installed, all cpus apic id is offset by 4, and bsp apic id is 4. For eight socket system with dual core cpus installed, all cpus apic id is offset by 2, and bsp apic id is 2. We need get boot_cpu_id --- bsp apic id, before k8_scan_nodes by called. So create early_acpi_boot_init and early_get_smp_config for get boot_cpu_id. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17x86: apic_is_clustered_box for vsmpYinghai Lu
quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters and that is larger than 2. So it is treated as a clustered_box. and will get: Marking TSC unstable due to TSCs unsynchronized even if the CPUs have X86_FEATURE_CONSTANT_TSC set. this quick fix will check if the cpu is from AMD. but vsmp still needs that checking... this patch is fix to make sure that vsmp not to be passed. Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>