1. 18 5月, 2012 3 次提交
  2. 29 3月, 2012 1 次提交
  3. 23 3月, 2012 1 次提交
    • S
      x86/apic: Add separate apic_id_valid() functions for selected apic drivers · b7157acf
      Steffen Persvold 提交于
      As suggested by Suresh Siddha and Yinghai Lu:
      
      For x2apic pre-enabled systems, apic driver is set already early
      through early_acpi_boot_init()/early_acpi_process_madt()/
      acpi_parse_madt()/default_acpi_madt_oem_check() path so that
      apic_id_valid() checking will be sufficient during MADT and SRAT
      parsing.
      
      For non-x2apic pre-enabled systems, all apic ids should be less
      than 255.
      
      This allows us to substitute the checks in
      arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() and
      arch/x86/mm/srat.c::acpi_numa_x2apic_affinity_init() with
      apic->apic_id_valid().
      
      In addition we can avoid feigning the x2apic cpu feature in the
      NumaChip apic code.
      
      The following apic drivers have separate apic_id_valid()
      functions which will accept x2apic type IDs :
      
       x2apic_phys
       x2apic_cluster
       x2apic_uv_x
       apic_numachip
      Signed-off-by: NSteffen Persvold <sp@numascale.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Daniel J Blueman <daniel@numascale-asia.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/1331925935-13372-1-git-send-email-sp@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b7157acf
  4. 14 3月, 2012 1 次提交
  5. 24 12月, 2011 2 次提交
  6. 18 12月, 2011 1 次提交
  7. 14 12月, 2011 1 次提交
    • F
      x86: Add per-cpu stat counter for APIC ICR read tries · 346b46be
      Fernando Luis Vázquez Cao 提交于
      In the IPI delivery slow path (NMI delivery) we retry the ICR
      read to check for delivery completion a limited number of times.
      
      [ The reason for the limited retries is that some of the places
        where it is used (cpu boot, kdump, etc) IPI delivery might not
        succeed (due to a firmware bug or system crash, for example)
        and in such a case it is better to give up and resume
        execution of other code. ]
      
      This patch adds a new entry to /proc/interrupts, RTR, which
      tells user space the number of times we retried the ICR read in
      the IPI delivery slow path.
      
      This should give some insight into how well the APIC
      message delivery hardware is working - if the counts are way
      too large then we are hitting a (very-) slow path way too
      often.
      Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Cc: Jörn Engel <joern@logfs.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/n/tip-vzsp20lo2xdzh5f70g0eis2s@git.kernel.org
      [ extended the changelog ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      346b46be
  8. 10 11月, 2011 1 次提交
  9. 29 9月, 2011 1 次提交
    • J
      apic, i386/bigsmp: Fix false warnings regarding logical APIC ID mismatches · 838312be
      Jan Beulich 提交于
      These warnings (generally one per CPU) are a result of
      initializing x86_cpu_to_logical_apicid while apic_default is
      still in use, but the check in setup_local_APIC() being done
      when apic_bigsmp was already used as an override in
      default_setup_apic_routing():
      
       Overriding APIC driver with bigsmp
       Enabling APIC mode:  Physflat.  Using 5 I/O APICs
       ------------[ cut here ]------------
       WARNING: at .../arch/x86/kernel/apic/apic.c:1239
       ...
       CPU 1 irqstacks, hard=f1c9a000 soft=f1c9c000
       Booting Node   0, Processors  #1
       smpboot cpu 1: start_ip = 9e000
       Initializing CPU#1
       ------------[ cut here ]------------
       WARNING: at .../arch/x86/kernel/apic/apic.c:1239
       setup_local_APIC+0x137/0x46b() Hardware name: ...
       CPU1 logical APIC ID: 2 != 8
       ...
      
      Fix this (for the time being, i.e. until
      x86_32_early_logical_apicid() will get removed again, as Tejun
      says ought to be possible) by overriding the previously stored
      values at the point where the APIC driver gets overridden.
      
      v2: Move this and the pre-existing override logic into
          arch/x86/kernel/apic/bigsmp_32.c.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: <stable@kernel.org> (2.6.39 and onwards)
      Link: http://lkml.kernel.org/r/4E835D16020000780005844C@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      838312be
  10. 27 7月, 2011 1 次提交
  11. 22 5月, 2011 3 次提交
  12. 02 5月, 2011 1 次提交
    • T
      x86-32, NUMA: Make apic->x86_32_numa_cpu_node() optional · 84914ed0
      Tejun Heo 提交于
      NUMAQ is the only meaningful user of this callback and
      setup_local_APIC() the only callsite.  Stop torturing everyone else by
      making the callback optional and removing all the boilerplate
      implementations and assignments.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      84914ed0
  13. 29 3月, 2011 1 次提交
    • J
      x86: Stop including <linux/delay.h> in two asm header files · ca444564
      Jean Delvare 提交于
      Stop including <linux/delay.h> in x86 header files which don't
      need it. This will let the compiler complain when this header is
      not included by source files when it should, so that
      contributors can fix the problem before building on other
      architectures starts to fail.
      
      Credits go to Geert for the idea.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: James E.J. Bottomley <James.Bottomley@suse.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20110325152014.297890ec@endymion.delvare>
      [ this also fixes an upstream build bug in drivers/media/rc/ite-cir.c ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ca444564
  14. 11 3月, 2011 1 次提交
  15. 25 2月, 2011 1 次提交
    • T
      x86: dt: Cleanup local apic setup · a906fdaa
      Thomas Gleixner 提交于
      Up to now we force enable the local apic in the devicetree setup
      uncoditionally and set smp_found_config unconditionally to 1 when a
      devicetree blob is available. This breaks, when local apic is disabled
      in the Kconfig.
      
      Make it consistent by initializing device tree explicitely before
      smp_get_config() so a non lapic configuration could be used as well.
      To be functional that would require to implement PIT as an interrupt
      host, but the only user of this code until now is ce4100 which
      requires apics to be available. So we leave this up to those who need
      it.
      Tested-by: NSebastian Siewior <bigeasy@linutronix.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      a906fdaa
  16. 10 2月, 2011 1 次提交
    • J
      x86: Fix section mismatch in LAPIC initialization · 2fb270f3
      Jan Beulich 提交于
      Additionally doing things conditionally upon smp_processor_id()
      being zero is generally a bad idea, as this means CPU 0 cannot
      be offlined and brought back online later again.
      
      While there may be other places where this is done, I think adding
      more of those should be avoided so that some day SMP can really
      become "symmetrical".
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      LKML-Reference: <4D525C7E0200007800030EE1@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2fb270f3
  17. 28 1月, 2011 4 次提交
    • T
      x86: Replace apic->apicid_to_node() with ->x86_32_numa_cpu_node() · 89e5dc21
      Tejun Heo 提交于
      apic->apicid_to_node() is 32bit specific apic operation which
      determines NUMA node for a CPU.  Depending on the APIC
      implementation, it can be easier to determine NUMA node from
      either physical or logical apicid.  Currently,
      ->apicid_to_node() takes @logical_apicid and calls
      hard_smp_processor_id() if the physical apicid is needed.
      
      This prevents NUMA mapping from being queried from a different
      CPU, which in turn makes it impossible to initialize NUMA
      mapping before SMP bringup.
      
      This patch replaces apic->apicid_to_node() with
      ->x86_32_numa_cpu_node() which takes @cpu, from which both
      logical and physical apicids can easily be determined.  While at
      it, drop duplicate implementations from bigsmp_32 and summit_32,
      and use the default one.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-13-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89e5dc21
    • T
      x86: Add apic->x86_32_early_logical_apicid() · acb8bc09
      Tejun Heo 提交于
      On x86_32, the mapping between cpu and logical apic ID differs
      depending on the specific apic implementation in use.  The
      mapping is initialized while bringing up CPUs; however, this
      makes early inits ignore memory topology.
      
      Add a x86_32 specific apic->x86_32_early_logical_apicid() which
      is called early during boot to query the mapping.  The mapping
      is later verified against the result of init_apic_ldr().  The
      method is allowed to return BAD_APICID if it can't be determined
      early.
      
      noop variant which always returns BAD_APICID is implemented and
      added to all x86_32 apic implementations.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: penberg@kernel.org
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-8-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      acb8bc09
    • T
      x86: Kill apic->cpu_to_logical_apicid() · 7632611f
      Tejun Heo 提交于
      After the previous patch, apic->cpu_to_logical_apicid() is no
      longer used.  Kill it.
      
      For apic types with custom cpu_to_logical_apicid() which is also
      used for other purposes, remove the function and modify its
      users to do the mapping directly.
      
      #ifdef's on CONFIG_SMP in es7000_32 and summit_32 are ignored
      during conversion as they are not used for UP kernels.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: penberg@kernel.org
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-7-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7632611f
    • T
      x86: Replace cpu_2_logical_apicid[] with early percpu variable · 4c321ff8
      Tejun Heo 提交于
      Unlike x86_64, on x86_32, the mapping from cpu to logical apicid
      may vary depending on apic in use.  cpu_2_logical_apicid[] array
      is used for this mapping.  Replace it with early percpu variable
      x86_cpu_to_logical_apicid to make it better aligned with other
      mappings.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: penberg@kernel.org
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-5-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4c321ff8
  18. 10 12月, 2010 2 次提交
  19. 10 11月, 2010 1 次提交
    • A
      x86: Address gcc4.6 "set but not used" warnings in apic.h · 0059b243
      Andi Kleen 提交于
      native_apic_msr_read() and x2apic_enabled() use rdmsr(msr, low, high),
      but only use the low part.
      
      gcc4.6 complains about this:
      .../apic.h:144:11: warning: variable 'high' set but not used [-Wunused-but-set-variable]
      
      rdmsr() is just a wrapper around rdmsrl() which splits the 64bit value
      into low and high, so using rdmsrl() directly solves this.
      
      [tglx: Changed the variables to u64 as suggested by Cyrill. It's less
             confusing and has no code impact as this is 64bit only anyway.
             Massaged changelog as well. ]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: x86@kernel.org
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      LKML-Reference: <1289251229-19589-1-git-send-email-andi@firstfloor.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      0059b243
  20. 23 10月, 2010 1 次提交
    • T
      x86: Allow platforms to force enable apic · 5a7ae78f
      Thomas Gleixner 提交于
      Some embedded x86 platforms don't setup the APIC in the
      BIOS/bootloader and would be forced to add "lapic" on the kernel
      command line. That's a bit akward.
      
      Split out the force enable code from detect_init_APIC() and allow
      platform code to call it from the platform setup. That avoids the
      command line parameter and possible replication of the MSR dance in
      the force enable code.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <1287510389-8388-1-git-send-email-dirk.brandewie@gmail.com>
      Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      5a7ae78f
  21. 20 10月, 2010 1 次提交
    • R
      apic, x86: Use BIOS settings for IBS and MCE threshold interrupt LVT offsets · 27afdf20
      Robert Richter 提交于
      We want the BIOS to setup the EILVT APIC registers. The offsets
      were hardcoded and BIOS settings were overwritten by the OS.
      Now, the subsystems for MCE threshold and IBS determine the LVT
      offset from the registers the BIOS has setup. If the BIOS setup
      is buggy on a family 10h system, a workaround enables IBS. If
      the OS determines an invalid register setup, a "[Firmware Bug]:
      " error message is reported.
      
      We need this change also for upcomming cpu families.
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      LKML-Reference: <1286360874-1471-3-git-send-email-robert.richter@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27afdf20
  22. 19 3月, 2010 1 次提交
    • C
      x86, apic: Allow to use certain functions without APIC built-in support · d674cd19
      Cyrill Gorcunov 提交于
      In case even if the kernel is configured so that
      no APIC support is built-in we still may allow
      to use certain apic functions as dummy calls.
      
      In particular we start using it in perf-events code.
      
      Note that this is not that same as NOOP apic driver (which
      is used if APIC support is present but no physical APIC is
      available), this is for the case when we don't have apic code
      compiled in at all.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <20100317104356.011052632@openvz.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d674cd19
  23. 10 11月, 2009 1 次提交
    • C
      x86: apic: Do not use stacked physid_mask_t · 7abc0753
      Cyrill Gorcunov 提交于
      We should not use physid_mask_t as a stack based
      variable in apic code. This type depends on MAX_APICS
      parameter which may be huge enough.
      
      Especially it became a problem with apic NOOP driver which
      is portable between 32 bit and 64 bit environment
      (where we have really huge MAX_APICS).
      
      So apic driver should operate with pointers and a caller
      in turn should aware of allocation physid_mask_t variable.
      
      As a side (but positive) effect -- we may use already
      implemented physid_set_mask_of_physid function eliminating
      default_apicid_to_cpu_present completely.
      
      Note that physids_coerce and physids_promote turned into static
      inline from macro (since macro hides the fact that parameter is
      being interpreted as unsigned long, make it explicit).
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20091109220659.GA5568@lenovo>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7abc0753
  24. 14 10月, 2009 1 次提交
    • C
      x86, apic: Introduce the NOOP apic driver · 9844ab11
      Cyrill Gorcunov 提交于
      Introduce NOOP APIC driver. We should use it in case if apic was
      disabled due to hardware of software/firmware problems (including
      user requested to disable it case).
      
      The driver is attempting to catch any inappropriate apic operation
      call with warning issue.
      
      Also it is possible to use some apic operation like IPI calls,
      read/write without checking for apic presence which should make
      callers code easier.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: yinghai@kernel.org
      Cc: macro@linux-mips.org
      LKML-Reference: <20091013201022.534682104@openvz.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9844ab11
  25. 21 9月, 2009 1 次提交
  26. 01 9月, 2009 1 次提交
  27. 31 8月, 2009 1 次提交
  28. 05 8月, 2009 1 次提交
    • G
      x86/apic: Enable x2APIC without interrupt remapping under KVM · ce69a784
      Gleb Natapov 提交于
      KVM would like to provide x2APIC interface to a guest without emulating
      interrupt remapping device. The reason KVM prefers guest to use x2APIC
      is that x2APIC interface is better virtualizable and provides better
      performance than mmio xAPIC interface:
      
       - msr exits are faster than mmio (no page table walk, emulation)
       - no need to read back ICR to look at the busy bit
       - one 64 bit ICR write instead of two 32 bit writes
       - shared code with the Hyper-V paravirt interface
      
      Included patch changes x2APIC enabling logic to enable it even if IR
      initialization failed, but kernel runs under KVM and no apic id is
      greater than 255 (if there is one spec requires BIOS to move to x2apic
      mode before starting an OS).
      
      -v2: fix build
      -v3: fix bug causing compiler warning
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Sheng Yang <sheng@linux.intel.com>
      Cc: "avi@redhat.com" <avi@redhat.com>
      LKML-Reference: <20090720122417.GR5638@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce69a784
  29. 09 6月, 2009 1 次提交
    • A
      x86: Detect use of extended APIC ID for AMD CPUs · 42937e81
      Andreas Herrmann 提交于
      Booting a 32-bit kernel on Magny-Cours results in the following panic:
      
        ...
        Using APIC driver default
        ...
        Overriding APIC driver with bigsmp
        ...
        Getting VERSION: 80050010
        Getting VERSION: 80050010
        Getting ID: 10000000
        Getting ID: ef000000
        Getting LVT0: 700
        Getting LVT1: 10000
        Kernel panic - not syncing: Boot APIC ID in local APIC unexpected (16 vs 0)
        Pid: 1, comm: swapper Not tainted 2.6.30-rcX #2
        Call Trace:
         [<c05194da>] ? panic+0x38/0xd3
         [<c0743102>] ? native_smp_prepare_cpus+0x259/0x31f
         [<c073b19d>] ? kernel_init+0x3e/0x141
         [<c073b15f>] ? kernel_init+0x0/0x141
         [<c020325f>] ? kernel_thread_helper+0x7/0x10
      
      The reason is that default_get_apic_id handled extension of local APIC
      ID field just in case of XAPIC.
      
      Thus for this AMD CPU, default_get_apic_id() returns 0 and
      bigsmp_get_apic_id() returns 16 which leads to the respective kernel
      panic.
      
      This patch introduces a Linux specific feature flag to indicate
      support for extended APIC id (8 bits instead of 4 bits width) and sets
      the flag on AMD CPUs if applicable.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090608135509.GA12431@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      42937e81
  30. 21 4月, 2009 1 次提交
  31. 19 4月, 2009 1 次提交