Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 4月, 2009 1 次提交
  3. 26 3月, 2009 1 次提交
  5. 25 3月, 2009 1 次提交
  7. 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
  9. 05 3月, 2009 1 次提交
  11. 26 2月, 2009 4 次提交
  13. 23 2月, 2009 1 次提交
  15. 18 2月, 2009 4 次提交
  17. 17 2月, 2009 2 次提交
  19. 11 2月, 2009 1 次提交
  21. 10 2月, 2009 1 次提交
  23. 29 1月, 2009 4 次提交
  25. 31 12月, 2008 1 次提交
  27. 27 12月, 2008 1 次提交
  29. 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
  31. 23 10月, 2008 2 次提交
  33. 16 10月, 2008 2 次提交
  35. 24 7月, 2008 1 次提交
  37. 23 7月, 2008 2 次提交
  39. 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
  41. 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
  43. 12 7月, 2008 2 次提交