1. 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
  2. 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
  3. 21 9月, 2009 1 次提交
  4. 01 9月, 2009 1 次提交
  5. 31 8月, 2009 1 次提交
  6. 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
  7. 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
  8. 21 4月, 2009 1 次提交
  9. 19 4月, 2009 2 次提交
    • W
      x86, intr-remap: enable interrupt remapping early · 93758238
      Weidong Han 提交于
      Currently, when x2apic is not enabled, interrupt remapping
      will be enabled in init_dmars(), where it is too late to remap
      ioapic interrupts, that is, ioapic interrupts are really in
      compatibility mode, not remappable mode.
      
      This patch always enables interrupt remapping before ioapic
      setup, it guarantees all interrupts will be remapped when
      interrupt remapping is enabled. Thus it doesn't need to set
      the compatibility interrupt bit.
      
      [ Impact: refactor intr-remap init sequence, enable fuller remap mode ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NWeidong Han <weidong.han@intel.com>
      Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: allen.m.kay@intel.com
      Cc: fenghua.yu@intel.com
      LKML-Reference: <1239957736-6161-4-git-send-email-weidong.han@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      93758238
    • W
      x86, intr-remap: fix ack for interrupt remapping · 5d0ae2db
      Weidong Han 提交于
      Shouldn't call ack_apic_edge() in ir_ack_apic_edge(), because
      ack_apic_edge() does more than just ack: it also does irq migration
      in the non-interrupt-remapping case. But there is no such need for
      interrupt-remapping case, as irq migration is done in the process
      context.
      
      Similarly, ir_ack_apic_level() shouldn't call ack_apic_level, and
      instead should do the local cpu's EOI + directed EOI to the io-apic.
      
      ack_x2APIC_irq() is not neccessary, because ack_APIC_irq() will use MSR
      write for x2apic, and uncached write for non-x2apic.
      
      [ Impact: simplify/standardize intr-remap IRQ acking, fix on !x2apic ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NWeidong Han <weidong.han@intel.com>
      Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: allen.m.kay@intel.com
      Cc: fenghua.yu@intel.com
      LKML-Reference: <1239957736-6161-3-git-send-email-weidong.han@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5d0ae2db
  10. 13 4月, 2009 1 次提交
    • C
      x86: apic - introduce dummy apic operations · 08306ce6
      Cyrill Gorcunov 提交于
      Impact: refactor, speed up and robustize code
      
      In case if apic was disabled by kernel option
      or by hardware limits we can use dummy operations
      in apic->write to simplify the ack_APIC_irq() code.
      
      At the lame time the patch fixes the missed EOI in
      do_IRQ function (which has place if kernel is compiled
      as X86-32 and interrupt without handler happens where
      apic was not asked to be disabled via kernel option).
      
      Note that native_apic_write_dummy() consists of
      WARN_ON_ONCE to catch any buggy writes on enabled
      APICs. Could be removed after some time of testing.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090412165058.724788431@openvz.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      08306ce6
  11. 12 4月, 2009 1 次提交
    • J
      x86: clean up declarations and variables · 2c1b284e
      Jaswinder Singh Rajput 提交于
      Impact: cleanup, no code changed
      
       - syscalls.h       update declarations due to unifications
       - irq.c            declare smp_generic_interrupt() before it gets used
       - process.c        declare sys_fork() and sys_vfork() before they get used
       - tsc.c            rename tsc_khz shadowed variable
       - apic/probe_32.c  declare apic_default before it gets used
       - apic/nmi.c       prev_nmi_count should be unsigned
       - apic/io_apic.c   declare smp_irq_move_cleanup_interrupt() before it gets used
       - mm/init.c        declare direct_gbpages and free_initrd_mem before they get used
      Signed-off-by: NJaswinder Singh Rajput <jaswinder@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2c1b284e
  12. 04 4月, 2009 2 次提交
  13. 26 3月, 2009 1 次提交
  14. 25 3月, 2009 1 次提交
  15. 18 3月, 2009 2 次提交
    • S
      x86: add x2apic_wrmsr_fence() to x2apic flush tlb paths · ce4e240c
      Suresh Siddha 提交于
      Impact: optimize APIC IPI related barriers
      
      Uncached MMIO accesses for xapic are inherently serializing and hence
      we don't need explicit barriers for xapic IPI paths.
      
      x2apic MSR writes/reads don't have serializing semantics and hence need
      a serializing instruction or mfence, to make all the previous memory
      stores globally visisble before the x2apic msr write for IPI.
      
      Add x2apic_wrmsr_fence() in flush tlb path to x2apic specific paths.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "steiner@sgi.com" <steiner@sgi.com>
      Cc: Nick Piggin <npiggin@suse.de>
      LKML-Reference: <1237313814.27006.203.camel@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce4e240c
    • S
      x86, x2apic: fix clear_local_APIC() in the presence of x2apic · cf6567fe
      Suresh Siddha 提交于
      Impact: cleanup, paranoia
      
      We were not clearing the local APIC in clear_local_APIC() in the
      presence of x2apic. Fix it.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      cf6567fe
  16. 05 3月, 2009 1 次提交
  17. 26 2月, 2009 4 次提交
  18. 23 2月, 2009 1 次提交
  19. 18 2月, 2009 4 次提交
  20. 17 2月, 2009 2 次提交
  21. 11 2月, 2009 1 次提交
  22. 10 2月, 2009 1 次提交
  23. 29 1月, 2009 4 次提交
  24. 31 12月, 2008 1 次提交
  25. 27 12月, 2008 1 次提交
  26. 11 11月, 2008 1 次提交
    • I
      x86: call machine_shutdown and stop all CPUs in native_machine_halt · d3ec5cae
      Ivan Vecera 提交于
      Impact: really halt all CPUs on halt
      
      Function machine_halt (resp. native_machine_halt) is empty for x86
      architectures. When command 'halt -f' is invoked, the message "System
      halted." is displayed but this is not really true because all CPUs are
      still running.
      
      There are also similar inconsistencies for other arches (some uses
      power-off for halt or forever-loop with IRQs enabled/disabled).
      
      IMO there should be used the same approach for all architectures OR
      what does the message "System halted" really mean?
      
      This patch fixes it for x86.
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3ec5cae
  27. 23 10月, 2008 1 次提交