1. 19 12月, 2015 1 次提交
  2. 26 11月, 2015 1 次提交
  3. 23 11月, 2015 1 次提交
  4. 19 11月, 2015 1 次提交
  5. 19 10月, 2015 2 次提交
  6. 17 8月, 2015 4 次提交
    • L
      x86/smpboot: Remove APIC.wait_for_init_deassert and atomic init_deasserted · 656bba30
      Len Brown 提交于
      Both the per-APIC flag ".wait_for_init_deassert",
      and the global atomic_t "init_deasserted"
      are dead code -- remove them.
      
      For all APIC types, "wait_for_master()"
      prevents an AP from proceeding until the BSP has set
      cpu_callout_mask, making "init_deasserted" {unnecessary}:
      
      	BSP: <de-assert INIT>
      	...
      	BSP: {set init_deasserted}
      	AP: wait_for_master()
      		set cpu_initialized_mask
      		wait for cpu_callout_mask
      	BSP: test cpu_initialized_mask
      	BSP: set cpu_callout_mask
      	AP: test cpu_callout_mask
      	AP: {wait for init_deasserted}
      	...
      	AP: <touch APIC>
      
      Deleting the {dead code} above is necessary to enable
      some parallelism in a future patch.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Link: http://lkml.kernel.org/r/de4b3a9bab894735e285870b5296da25ee6a8a5a.1439739165.git.len.brown@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      656bba30
    • L
      x86/smpboot: Remove SIPI delays from cpu_up() · a9bcaa02
      Len Brown 提交于
      MPS 1.4 example code shows the following required delays during processor
      on-lining:
      
      	INIT
      	 udelay(10,000)
      	SIPI
      	 udelay(200)
      	SIPI
      	 udelay(200) /* Linux actually implements this as udelay(300) */
      
      Linux skips the udelay(10,000) on modern processors.
      This patch removes the udelay(200) after each SIPI
      on those same processors.
      
      All three legacy delays can be restored by the cmdline
      "cpu_init_udelay=10000".
      
      As measured by analyze_suspend.py, this patch speeds
      processor resume time on my desktop from 2.4ms to 1.8ms, per AP.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Link: http://lkml.kernel.org/r/a5dfdbc8fbfdd813784da204aad5677fe459ac37.1439739165.git.len.brown@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a9bcaa02
    • L
      x86/smpboot: Remove udelay(100) when polling cpu_callin_map · 2d99af8e
      Len Brown 提交于
      After the BSP sends INIT/SIPI/SIP to the AP and sees the AP
      in the cpu_initialized_map, it sets the AP loose via the
      cpu_callout_map, and waits for it via the cpu_callin_map.
      
      The BSP polls the cpu_callin_map with a udelay(100)
      and a schedule() in each iteration.
      
      The udelay(100) adds no value.
      
      For example, on my 4-CPU dekstop, the AP finishes
      cpu_callin() in under 70 usec and sets the cpu_callin_mask.
      The BSP, however, doesn't see that setting until over 30 usec
      later, because it was still running its udelay(100)
      when the AP finished.
      
      Deleting the udelay(100) in the cpu_callin_mask polling loop,
      saves from 0 to 100 usec per Application Processor.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Link: http://lkml.kernel.org/r/0aade12eabeb89a688c929fe80856eaea0544bb7.1439739165.git.len.brown@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2d99af8e
    • L
      x86/smpboot: Remove udelay(100) when polling cpu_initialized_map · 6e38f1e7
      Len Brown 提交于
      After the BSP sends the APIC INIT/SIPI/SIPI to the AP,
      it waits for the AP to come up and indicate that it is alive
      by setting its own bit in the cpu_initialized_mask.
      
      Linux polls for up to 10 seconds for this to happen.
      Each polling loop has a udelay(100) and a call to schedule().
      
      The udelay(100) adds no value.
      
      For example, on my desktop, the BSP waits for the
      other 3 CPUs to come on line at boot for 305, 404, 405 usec.
      For resume from S3, it waits 317, 404, 405 usec.
      
      But when the udelay(100) is removed, the BSP waits
      305, 310, 306 for boot, and 305, 307, 306 for resume.
      
      So for both boot and resume, removing the udelay(100)
      speeds online by about 100us in 2 of 3 cases.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Link: http://lkml.kernel.org/r/33ef746c67d2489cad0a9b1958cf71167232ff2b.1439739165.git.len.brown@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6e38f1e7
  7. 21 7月, 2015 1 次提交
  8. 15 7月, 2015 1 次提交
    • T
      genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now · ce0d3c0a
      Thomas Gleixner 提交于
      Boris reported that the sparse_irq protection around __cpu_up() in the
      generic code causes a regression on Xen. Xen allocates interrupts and
      some more in the xen_cpu_up() function, so it deadlocks on the
      sparse_irq_lock.
      
      There is no simple fix for this and we really should have the
      protection for all architectures, but for now the only solution is to
      move it to x86 where actual wreckage due to the lack of protection has
      been observed.
      Reported-and-tested-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Fixes: a8994181 'hotplug: Prevent alloc/free of irq descriptors during cpu up/down'
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: xiao jin <jin.xiao@intel.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Cc: xen-devel <xen-devel@lists.xenproject.org>
      ce0d3c0a
  9. 07 7月, 2015 1 次提交
    • T
      x86/irq: Plug irq vector hotplug race · 5a3f75e3
      Thomas Gleixner 提交于
      Jin debugged a nasty cpu hotplug race which results in leaking a irq
      vector on the newly hotplugged cpu.
      
      cpu N				cpu M
      native_cpu_up                   device_shutdown
        do_boot_cpu			  free_msi_irqs
        start_secondary                   arch_teardown_msi_irqs
          smp_callin                        default_teardown_msi_irqs
             setup_vector_irq                  arch_teardown_msi_irq
              __setup_vector_irq		   native_teardown_msi_irq
                lock(vector_lock)		     destroy_irq 
                install vectors
                unlock(vector_lock)
      					       lock(vector_lock)
      --->                                  	       __clear_irq_vector
                                          	       unlock(vector_lock)
          lock(vector_lock)
          set_cpu_online
          unlock(vector_lock)
      
      This leaves the irq vector(s) which are torn down on CPU M stale in
      the vector array of CPU N, because CPU M does not see CPU N online
      yet. There is a similar issue with concurrent newly setup interrupts.
      
      The alloc/free protection of irq descriptors does not prevent the
      above race, because it merily prevents interrupt descriptors from
      going away or changing concurrently.
      
      Prevent this by moving the call to setup_vector_irq() into the
      vector_lock held region which protects set_cpu_online():
      
      cpu N				cpu M
      native_cpu_up                   device_shutdown
        do_boot_cpu			  free_msi_irqs
        start_secondary                   arch_teardown_msi_irqs
          smp_callin                        default_teardown_msi_irqs
             lock(vector_lock)                arch_teardown_msi_irq
             setup_vector_irq()
              __setup_vector_irq		   native_teardown_msi_irq
                install vectors		     destroy_irq 
             set_cpu_online
             unlock(vector_lock)
      					       lock(vector_lock)
                                        	       __clear_irq_vector
                                          	       unlock(vector_lock)
      
      So cpu M either sees the cpu N online before clearing the vector or
      cpu N installs the vectors after cpu M has cleared it.
      Reported-by: Nxiao jin <jin.xiao@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20150705171102.141898931@linutronix.de
      5a3f75e3
  10. 06 7月, 2015 2 次提交
  11. 27 5月, 2015 1 次提交
  12. 19 5月, 2015 2 次提交
    • I
      x86/fpu: Rename fpu-internal.h to fpu/internal.h · 78f7f1e5
      Ingo Molnar 提交于
      This unifies all the FPU related header files under a unified, hiearchical
      naming scheme:
      
       - asm/fpu/types.h:      FPU related data types, needed for 'struct task_struct',
                               widely included in almost all kernel code, and hence kept
                               as small as possible.
      
       - asm/fpu/api.h:        FPU related 'public' methods exported to other subsystems.
      
       - asm/fpu/internal.h:   FPU subsystem internal methods
      
       - asm/fpu/xsave.h:      XSAVE support internal methods
      
      (Also standardize the header guard in asm/fpu/internal.h.)
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      78f7f1e5
    • I
      x86/fpu: Fix header file dependencies of fpu-internal.h · f89e32e0
      Ingo Molnar 提交于
      Fix a minor header file dependency bug in asm/fpu-internal.h: it
      relies on i387.h but does not include it. All users of fpu-internal.h
      included it explicitly.
      
      Also remove unnecessary includes, to reduce compilation time.
      
      This also makes it easier to use it as a standalone header file
      for FPU internals, such as an upcoming C module in arch/x86/kernel/fpu/.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f89e32e0
  13. 18 5月, 2015 1 次提交
    • I
      x86/smp/boot: Fix legacy SMP bootup slow-boot bug · 7cb68598
      Ingo Molnar 提交于
      So while testing kernels using tools/kvm/ (kvmtool) I noticed that it
      booted super slow:
      
      [    0.142991] Performance Events: no PMU driver, software events only.
      [    0.149265] x86: Booting SMP configuration:
      [    0.149765] .... node  #0, CPUs:          #1
      [    0.148304] kvm-clock: cpu 1, msr 2:1bfe9041, secondary cpu clock
      [   10.158813] KVM setup async PF for cpu 1
      [   10.159000]    #2
      [   10.159000] kvm-stealtime: cpu 1, msr 211a4d400
      [   10.158829] kvm-clock: cpu 2, msr 2:1bfe9081, secondary cpu clock
      [   20.167805] KVM setup async PF for cpu 2
      [   20.168000]    #3
      [   20.168000] kvm-stealtime: cpu 2, msr 211a8d400
      [   20.167818] kvm-clock: cpu 3, msr 2:1bfe90c1, secondary cpu clock
      [   30.176902] KVM setup async PF for cpu 3
      [   30.177000]    #4
      [   30.177000] kvm-stealtime: cpu 3, msr 211acd400
      
      One CPU booted up per 10 seconds. With 120 CPUs that takes a while.
      
      Bisection pinpointed this commit:
      
        853b160a ("Revert f5d6a52f ("x86/smpboot: Skip delays during SMP initialization similar to Xen")")
      
      But that commit just restores previous behavior, so it cannot cause the
      problem. After some head scratching it turns out that these two commits:
      
        1a744cb3 ("x86/smp/boot: Remove 10ms delay from cpu_up() on modern processors")
        d68921f9 ("x86/smp/boot: Add cmdline "cpu_init_udelay=N" to specify cpu_up() delay")
      
      added the following code to smpboot.c:
      
      -               mdelay(10);
      +               mdelay(init_udelay);
      
      Note the mismatch in the units: the delay is called 'udelay' and is set
      to microseconds - while the function used here is actually 'mdelay',
      which counts in milliseconds ...
      
      So the delay for legacy systems is off by a factor of 1,000, so instead
      of 10 msecs we waited for 10 seconds ...
      
      The reason bisection pointed to 853b160a was that 853b160a removed
      a (broken) boot-time speedup patch, which masked the factor 1,000 bug.
      
      Fix it by using udelay(). This fixes my bootup problems.
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      7cb68598
  14. 13 5月, 2015 1 次提交
    • I
      Revert f5d6a52f ("x86/smpboot: Skip delays during SMP initialization similar to Xen") · 853b160a
      Ingo Molnar 提交于
      Huang Ying reported x86 boot hangs due to this commit.
      
      Turns out that the change, despite its changelog, does more
      than just change timeouts: it also changes the way we
      assert/deassert INIT via the APIC_DM_INIT IPI, in the x2apic
      case it skips the deassert step.
      
      This is historically fragile code and the patch did not
      improve it, so revert these changes.
      
      This commit:
      
        1a744cb3 ("x86/smp/boot: Remove 10ms delay from cpu_up() on modern processors")
      
      independently removes the worst of the delays (the 10 msec delay).
      
      The remaining delays can be addressed one by one, combined
      with careful testing.
      Reported-by: NHuang Ying <ying.huang@intel.com>
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Gang Wei <gang.wei@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tim Deegan <tim@xen.org>
      Link: http://lkml.kernel.org/r/1430732554-7294-1-git-send-email-jschoenh@amazon.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      853b160a
  15. 12 5月, 2015 2 次提交
  16. 08 5月, 2015 1 次提交
  17. 06 5月, 2015 1 次提交
    • J
      x86/smpboot: Skip delays during SMP initialization similar to Xen · f5d6a52f
      Jan H. Schönherr 提交于
      Remove the per-CPU delays during SMP initialization, which seems
      to be possible on newer architectures with an x2APIC.
      
      Xen does this since 2011. In fact, this commit is basically a
      combination of the following Xen commits. The first removes the
      delays, the second fixes an issue with the removal:
      
        commit 68fce206f6dba9981e8322269db49692c95ce250
        Author: Tim Deegan <Tim.Deegan@citrix.com>
        Date:   Tue Jul 19 14:13:01 2011 +0100
      
          x86: Remove timeouts from INIT-SIPI-SIPI sequence when using x2apic.
      
          Some of the timeouts are pointless since they're waiting for the ICR
          to ack the IPI delivery and that doesn't happen on x2apic.
          The others should be benign (and are suggested in the SDM) but
          removing them makes AP bringup much more reliable on some test boxes.
      Signed-off-by: NTim Deegan <Tim.Deegan@citrix.com>
      
        commit f12ee533150761df5a7099c83f2a5fa6c07d1187
        Author: Gang Wei <gang.wei@intel.com>
        Date:   Thu Dec 29 10:07:54 2011 +0000
      
          X86: Add a delay between INIT & SIPIs for tboot AP bring-up in X2APIC case
      
          Without this delay, Xen could not bring APs up while working with
          TXT/tboot, because tboot needs some time in APs to handle INIT before
          becoming ready for receiving SIPIs (this delay was removed as part of
          c/s 23724 by Tim Deegan).
      Signed-off-by: NGang Wei <gang.wei@intel.com>
      Acked-by: NKeir Fraser <keir@xen.org>
      Acked-by: NTim Deegan <tim@xen.org>
      Committed-by: NTim Deegan <tim@xen.org>
      Signed-off-by: NJan H. Schönherr <jschoenh@amazon.de>
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Gang Wei <gang.wei@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tim Deegan <tim@xen.org>
      Link: http://lkml.kernel.org/r/1430732554-7294-1-git-send-email-jschoenh@amazon.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f5d6a52f
  18. 02 4月, 2015 1 次提交
  19. 01 4月, 2015 1 次提交
  20. 25 3月, 2015 1 次提交
    • D
      x86/asm/entry: Get rid of KERNEL_STACK_OFFSET · ef593260
      Denys Vlasenko 提交于
      PER_CPU_VAR(kernel_stack) was set up in a way where it points
      five stack slots below the top of stack.
      
      Presumably, it was done to avoid one "sub $5*8,%rsp"
      in syscall/sysenter code paths, where iret frame needs to be
      created by hand.
      
      Ironically, none of them benefits from this optimization,
      since all of them need to allocate additional data on stack
      (struct pt_regs), so they still have to perform subtraction.
      
      This patch eliminates KERNEL_STACK_OFFSET.
      
      PER_CPU_VAR(kernel_stack) now points directly to top of stack.
      pt_regs allocations are adjusted to allocate iret frame as well.
      Hopefully we can merge it later with 32-bit specific
      PER_CPU_VAR(cpu_current_top_of_stack) variable...
      
      Net result in generated code is that constants in several insns
      are changed.
      
      This change is necessary for changing struct pt_regs creation
      in SYSCALL64 code path from MOV to PUSH instructions.
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Drewry <wad@chromium.org>
      Link: http://lkml.kernel.org/r/1426785469-15125-2-git-send-email-dvlasenk@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ef593260
  21. 12 3月, 2015 1 次提交
    • P
      x86: Use common outgoing-CPU-notification code · 2a442c9c
      Paul E. McKenney 提交于
      This commit removes the open-coded CPU-offline notification with new
      common code.  Among other things, this change avoids calling scheduler
      code using RCU from an offline CPU that RCU is ignoring.  It also allows
      Xen to notice at online time that the CPU did not go offline correctly.
      Note that Xen has the surviving CPU carry out some cleanup operations,
      so if the surviving CPU times out, these cleanup operations might have
      been carried out while the outgoing CPU was still running.  It might
      therefore be unwise to bring this CPU back online, and this commit
      avoids doing so.
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: <x86@kernel.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: <xen-devel@lists.xenproject.org>
      2a442c9c
  22. 07 3月, 2015 1 次提交
  23. 22 1月, 2015 6 次提交
  24. 16 12月, 2014 1 次提交
  25. 10 11月, 2014 1 次提交
  26. 05 11月, 2014 1 次提交
  27. 19 10月, 2014 1 次提交
  28. 03 10月, 2014 1 次提交