1. 06 Apr, 2012 1 commit
  2. 22 Mar, 2012 1 commit
    • Konrad Rzeszutek Wilk's avatar
      xen/smp: Fix bringup bug in AP code. · 106b4438
      Konrad Rzeszutek Wilk authored
      The CPU hotplug code has now a callback to help bring up the CPU.
      Without the call we end up getting:
       BUG: soft lockup - CPU#0 stuck for 29s! [migration/0:6]
      Modules linked in:
      CPU ] Pid: 6, comm: migration/0 Not tainted 3.3.0upstream-01180-ged378a52
       #1 Dell Inc. PowerEdge T105 /0RR825
      RIP: e030:[<ffffffff810d3b8b>]  [<ffffffff810d3b8b>] stop_machine_cpu_stop+0x7b/0xf0
      RSP: e02b:ffff8800ceaabdb0  EFLAGS: 00000293
      .. snip..
      Call Trace:
       [<ffffffff810d3b10>] ? stop_one_cpu_nowait+0x50/0x50
       [<ffffffff810d3841>] cpu_stopper_thread+0xf1/0x1c0
       [<ffffffff815a9776>] ? __schedule+0x3c6/0x760
       [<ffffffff815aa749>] ? _raw_spin_unlock_irqrestore+0x19/0x30
       [<ffffffff810d3750>] ? res_counter_charge+0x150/0x150
       [<ffffffff8108dc76>] kthread+0x96/0xa0
       [<ffffffff815b27e4>] kernel_thread_helper+0x4/0x10
       [<ffffffff815aacbc>] ? retint_restore_ar
      Thix fixes it.
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  3. 03 Feb, 2012 1 commit
    • Konrad Rzeszutek Wilk's avatar
      xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic. · 41bd956d
      Konrad Rzeszutek Wilk authored
      When a user offlines a VCPU and then onlines it, we get:
      NMI watchdog disabled (cpu2): hardware events not enabled
      BUG: scheduling while atomic: swapper/2/0/0x00000002
      Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod libcrc32c crc32c radeon fbco
       ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:
      Pid: 0, comm: swapper/2 Tainted: G           O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
      Call Trace:
       [<ffffffff81070571>] __schedule_bug+0x61/0x70
       [<ffffffff8158eb78>] __schedule+0x798/0x850
       [<ffffffff8158ed6a>] schedule+0x3a/0x50
       [<ffffffff810349be>] cpu_idle+0xbe/0xe0
       [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10
      The reason for this should be obvious from this call-chain:
       \- cpu_bringup
        |   \-[preempt_disable]
        |- cpu_idle
             \- play_dead [assuming the user offlined the VCPU]
             |     \
             |     +- (xen_play_dead)
             |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
             |          |                       onlines it starts from here]
             |          \- cpu_bringup [preempt_disable]
             +- preempt_enable_no_reschedule()
             +- schedule()
             \- preempt_enable()
      So we have two preempt_disble() and one preempt_enable(). Calling
      preempt_enable() after the cpu_bringup() in the xen_play_dead
      fixes the imbalance.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  4. 24 Jan, 2012 1 commit
  5. 08 Sep, 2011 1 commit
  6. 01 Sep, 2011 1 commit
  7. 22 Aug, 2011 1 commit
  8. 15 Jun, 2011 1 commit
    • Andrew Jones's avatar
      xen: support CONFIG_MAXSMP · 900cba88
      Andrew Jones authored
      The MAXSMP config option requires CPUMASK_OFFSTACK, which in turn
      requires we init the memory for the maps while we bring up the cpus.
      MAXSMP also increases NR_CPUS to 4096. This increase in size exposed an
      issue in the argument construction for multicalls from
      xen_flush_tlb_others. The args should only need space for the actual
      number of cpus.
      Also in 2.6.39 it exposes a bootup problem.
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff8157a1d3>] set_cpu_sibling_map+0x123/0x30d
      Call Trace:
      [<ffffffff81039a3f>] ? xen_restore_fl_direct_reloc+0x4/0x4
      [<ffffffff819dc4db>] xen_smp_prepare_cpus+0x36/0x135
      CC: stable@kernel.org
      Signed-off-by: Andrew Jones's avatarAndrew Jones <drjones@redhat.com>
      [v2: Updated to compile on 3.0]
      [v3: Updated to compile when CONFIG_SMP is not defined]
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  9. 19 May, 2011 1 commit
  10. 14 Apr, 2011 1 commit
  11. 25 Feb, 2011 1 commit
  12. 26 Oct, 2010 1 commit
    • Stefano Stabellini's avatar
      xen: initialize cpu masks for pv guests in xen_smp_init · ea5b8f73
      Stefano Stabellini authored
      Pv guests don't have ACPI and need the cpu masks to be set
      correctly as early as possible so we call xen_fill_possible_map from
      On the other hand the initial domain supports ACPI so in this case we skip
      xen_fill_possible_map and rely on it. However Xen might limit the number
      of cpus usable by the domain, so we filter those masks during smp
      initialization using the VCPUOP_is_up hypercall.
      It is important that the filtering is done before
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
  13. 22 Oct, 2010 1 commit
  14. 21 Oct, 2010 1 commit
    • Alok Kataria's avatar
      x86, kexec: Make sure to stop all CPUs before exiting the kernel · 76fac077
      Alok Kataria authored
      x86 smp_ops now has a new op, stop_other_cpus which takes a parameter
      "wait" this allows the caller to specify if it wants to stop until all
      the cpus have processed the stop IPI.  This is required specifically
      for the kexec case where we should wait for all the cpus to be stopped
      before starting the new kernel.  We now wait for the cpus to stop in
      all cases except for panic/kdump where we expect things to be broken
      and we are doing our best to make things work anyway.
      This patch fixes a legitimate regression, which was introduced during
      2.6.30, by commit id 4ef702c1
      Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: <stable@kernel.org> v2.6.30-36
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  15. 04 Aug, 2010 1 commit
  16. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      The script does the followings.
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
      The conversion was done in the following steps.
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
      6. percpu.h was updated not to include slab.h.
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
  17. 05 Feb, 2010 1 commit
  18. 03 Dec, 2009 1 commit
  19. 04 Nov, 2009 1 commit
  20. 29 Oct, 2009 1 commit
    • Tejun Heo's avatar
      percpu: make percpu symbols in xen unique · c6e22f9e
      Tejun Heo authored
      This patch updates percpu related symbols in xen such that percpu
      symbols are unique and don't clash with local symbols.  This serves
      two purposes of decreasing the possibility of global percpu symbol
      collision and allowing dropping per_cpu__ prefix from percpu symbols.
      * arch/x86/xen/smp.c, arch/x86/xen/time.c, arch/ia64/xen/irq_xen.c:
        add xen_ prefix to percpu variables
      * arch/ia64/xen/time.c: add xen_ prefix to percpu variables, drop
        processed_ prefix and make them static
      Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
      which cause name clashes" patch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
  21. 09 Sep, 2009 1 commit
    • Jeremy Fitzhardinge's avatar
      xen: make -fstack-protector work under Xen · 577eebea
      Jeremy Fitzhardinge authored
      -fstack-protector uses a special per-cpu "stack canary" value.
      gcc generates special code in each function to test the canary to make
      sure that the function's stack hasn't been overrun.
      On x86-64, this is simply an offset of %gs, which is the usual per-cpu
      base segment register, so setting it up simply requires loading %gs's
      base as normal.
      On i386, the stack protector segment is %gs (rather than the usual kernel
      percpu %fs segment register).  This requires setting up the full kernel
      GDT and then loading %gs accordingly.  We also need to make sure %gs is
      initialized when bringing up secondary cpus too.
      To keep things consistent, we do the full GDT/segment register setup on
      both architectures.
      Because we need to avoid -fstack-protected code before setting up the GDT
      and because there's no way to disable it on a per-function basis, several
      files need to have stack-protector inhibited.
      [ Impact: allow Xen booting with stack-protector enabled ]
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
  22. 08 Apr, 2009 1 commit
  23. 30 Mar, 2009 1 commit
  24. 13 Mar, 2009 1 commit
  25. 02 Mar, 2009 1 commit
    • Jeremy Fitzhardinge's avatar
      xen: deal with virtually mapped percpu data · 9976b39b
      Jeremy Fitzhardinge authored
      The virtually mapped percpu space causes us two problems:
       - for hypercalls which take an mfn, we need to do a full pagetable
         walk to convert the percpu va into an mfn, and
       - when a hypercall requires a page to be mapped RO via all its aliases,
         we need to make sure its RO in both the percpu mapping and in the
         linear mapping
      This primarily affects the gdt and the vcpu info structure.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Xen-devel <xen-devel@lists.xensource.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  26. 05 Feb, 2009 1 commit
  27. 31 Jan, 2009 1 commit
  28. 27 Jan, 2009 1 commit
  29. 18 Jan, 2009 2 commits
  30. 16 Jan, 2009 2 commits
    • Ingo Molnar's avatar
      percpu: add optimized generic percpu accessors · 6dbde353
      Ingo Molnar authored
      It is an optimization and a cleanup, and adds the following new
      generic percpu methods:
      and implements support for them on x86. (other architectures will fall
      back to a default implementation)
      The advantage is that for example to read a local percpu variable,
      instead of this sequence:
       return __get_cpu_var(var);
       ffffffff8102ca2b:	48 8b 14 fd 80 09 74 	mov    -0x7e8bf680(,%rdi,8),%rdx
       ffffffff8102ca32:	81
       ffffffff8102ca33:	48 c7 c0 d8 59 00 00 	mov    $0x59d8,%rax
       ffffffff8102ca3a:	48 8b 04 10          	mov    (%rax,%rdx,1),%rax
      We can get a single instruction by using the optimized variants:
       return percpu_read(var);
       ffffffff8102ca3f:	65 48 8b 05 91 8f fd 	mov    %gs:0x7efd8f91(%rip),%rax
      I also cleaned up the x86-specific APIs and made the x86 code use
      these new generic percpu primitives.
      tj: * fixed generic percpu_sub() definition as Roel Kluin pointed out
          * added percpu_and() for completeness's sake
          * made generic percpu ops atomic against preemption
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
    • Tejun Heo's avatar
      x86: fold pda into percpu area on SMP · 1a51e3a0
      Tejun Heo authored
      [ Based on original patch from Christoph Lameter and Mike Travis. ]
      Currently pdas and percpu areas are allocated separately.  %gs points
      to local pda and percpu area can be reached using pda->data_offset.
      This patch folds pda into percpu area.
      Due to strange gcc requirement, pda needs to be at the beginning of
      the percpu area so that pda->stack_canary is at %gs:40.  To achieve
      this, a new percpu output section macro - PERCPU_VADDR_PREALLOC() - is
      added and used to reserve pda sized chunk at the start of the percpu
      After this change, for boot cpu, %gs first points to pda in the
      data.init area and later during setup_per_cpu_areas() gets updated to
      point to the actual pda.  This means that setup_per_cpu_areas() need
      to reload %gs for CPU0 while clearing pda area for other cpus as cpu0
      already has modified it when control reaches setup_per_cpu_areas().
      This patch also removes now unnecessary get_local_pda() and its call
      A lot of this patch is taken from Mike Travis' "x86_64: Fold pda into
      per cpu area" patch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  31. 17 Dec, 2008 3 commits
  32. 30 Nov, 2008 1 commit
  33. 08 Sep, 2008 2 commits
  34. 25 Aug, 2008 1 commit
    • Alex Nixon's avatar
      xen: implement CPU hotplugging · d68d82af
      Alex Nixon authored
      Note the changes from 2.6.18-xen CPU hotplugging:
      A vcpu_down request from the remote admin via Xenbus both hotunplugs the
      CPU, and disables it by removing it from the cpu_present map, and removing
      its entry in /sys.
      A vcpu_up request from the remote admin only re-enables the CPU, and does
      not immediately bring the CPU up. A udev event is emitted, which can be
      caught by the user if he wishes to automatically re-up CPUs when available,
      or implement a more complex policy.
      Signed-off-by: default avatarAlex Nixon <alex.nixon@citrix.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  35. 24 Jul, 2008 1 commit