1. 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
  2. 23 10月, 2008 2 次提交
  3. 16 10月, 2008 2 次提交
  4. 24 7月, 2008 1 次提交
  5. 23 7月, 2008 2 次提交
  6. 22 7月, 2008 2 次提交
    • S
      x64, apic: use generic apic_write() for ack_APIC_irq() · df1be437
      Suresh Siddha 提交于
      I tested tip/master and found an issue (patch attached)
      for x2apic support. This is not because of the recent merges we had, but
      because of something(where we still access memory based interface after
      enabling x2apic mode) that slipped through my earlier tests.
      
      Probably it is a good idea to unmap the memory mapped interface, once we switch
      to x2apic mode. That will catch the issues much earlier. I will
      post another patch for this.
      
      ack_APIC_irq() is used at too many generic places (and not just during
      irq_chip handling!) to use the native_apic_mem_write(). For ex, this will
      break x2apic based systems.
      
      Fix ack_APIC_irq() to use the generic apic_write() even for 64-bit.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: suresh.b.siddha@intel.com
      Cc: yong.y.wang@linux.intel.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      df1be437
    • T
      x86: convert Dprintk to pr_debug · cfc1b9a6
      Thomas Gleixner 提交于
      There are a couple of places where (P)Dprintk is used which is an old
      compile time enabled printk wrapper. Convert it to the generic
      pr_debug().
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      cfc1b9a6
  7. 18 7月, 2008 3 次提交
    • M
      x86: more apic debugging · 35b68055
      Maciej W. Rozycki 提交于
      [ mingo@elte.hu: picked up this patch from Maciej, lets make apic=debug
                       print out more info - we had a lot of APIC changes ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      35b68055
    • M
      x86: APIC: Make apic_verbosity unsigned · baa13188
      Maciej 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: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      baa13188
    • M
      x86: APIC: remove apic_write_around(); use alternatives · 593f4a78
      Maciej W. Rozycki 提交于
      Use alternatives to select the workaround for the 11AP Pentium erratum
      for the affected steppings on the fly rather than build time.  Remove the
      X86_GOOD_APIC configuration option and replace all the calls to
      apic_write_around() with plain apic_write(), protecting accesses to the
      ESR as appropriate due to the 3AP Pentium erratum.  Remove
      apic_read_around() and all its invocations altogether as not needed.
      Remove apic_write_atomic() and all its implementing backends.  The use of
      ASM_OUTPUT2() is not strictly needed for input constraints, but I have
      used it for readability's sake.
      
      I had the feeling no one else was brave enough to do it, so I went ahead
      and here it is.  Verified by checking the generated assembly and tested
      with both a 32-bit and a 64-bit configuration, also with the 11AP
      "feature" forced on and verified with gdb on /proc/kcore to work as
      expected (as an 11AP machines are quite hard to get hands on these days).
      Some script complained about the use of "volatile", but apic_write() needs
      it for the same reason and is effectively a replacement for writel(), so I
      have disregarded it.
      
      I am not sure what the policy wrt defconfig files is, they are generated
      and there is risk of a conflict resulting from an unrelated change, so I
      have left changes to them out.  The option will get removed from them at
      the next run.
      
      Some testing with machines other than mine will be needed to avoid some
      stupid mistake, but despite its volume, the change is not really that
      intrusive, so I am fairly confident that because it works for me, it will
      everywhere.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      593f4a78
  8. 12 7月, 2008 5 次提交
    • Y
      x86: let 32bit use apic_ops too · c535b6a1
      Yinghai Lu 提交于
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c535b6a1
    • S
      x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping · 6e1cb38a
      Suresh Siddha 提交于
      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: NSuresh 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: NIngo Molnar <mingo@elte.hu>
      6e1cb38a
    • S
      x64, x2apic/intr-remap: IO-APIC support for interrupt-remapping · 89027d35
      Suresh 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: NSuresh 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: NIngo Molnar <mingo@elte.hu>
      89027d35
    • S
      x64, x2apic/intr-remap: x2apic ops for x2apic mode support · 13c88fb5
      Suresh Siddha 提交于
      x2apic ops for x2apic mode support. This uses MSR interface and differs
      slightly from the xapic register layout.
      Signed-off-by: NSuresh 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: NIngo Molnar <mingo@elte.hu>
      13c88fb5
    • S
      x64, x2apic/intr-remap: basic apic ops support · 1b374e4d
      Suresh 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: NSuresh 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: NIngo Molnar <mingo@elte.hu>
      1b374e4d
  9. 09 7月, 2008 1 次提交
  10. 08 7月, 2008 5 次提交
  11. 17 4月, 2008 6 次提交
  12. 30 1月, 2008 7 次提交
  13. 11 10月, 2007 1 次提交