1. 08 4月, 2013 1 次提交
  2. 20 2月, 2013 1 次提交
  3. 16 1月, 2013 1 次提交
  4. 18 12月, 2012 1 次提交
  5. 23 8月, 2012 1 次提交
    • R
      x86/smp: Don't ever patch back to UP if we unplug cpus · 816afe4f
      Rusty Russell 提交于
      We still patch SMP instructions to UP variants if we boot with a
      single CPU, but not at any other time.  In particular, not if we
      unplug CPUs to return to a single cpu.
      
      Paul McKenney points out:
      
       mean offline overhead is 6251/48=130.2 milliseconds.
      
       If I remove the alternatives_smp_switch() from the offline
       path [...] the mean offline overhead is 550/42=13.1 milliseconds
      
      Basically, we're never going to get those 120ms back, and the
      code is pretty messy.
      
      We get rid of:
      
       1) The "smp-alt-once" boot option. It's actually "smp-alt-boot", the
          documentation is wrong. It's now the default.
      
       2) The skip_smp_alternatives flag used by suspend.
      
       3) arch_disable_nonboot_cpus_begin() and arch_disable_nonboot_cpus_end()
          which were only used to set this one flag.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Paul McKenney <paul.mckenney@us.ibm.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/87vcgwwive.fsf@rustcorp.com.auSigned-off-by: NIngo Molnar <mingo@kernel.org>
      816afe4f
  6. 05 6月, 2012 1 次提交
  7. 21 5月, 2012 1 次提交
    • K
      xen/smp: unbind irqworkX when unplugging vCPUs. · 2f1bd67d
      Konrad Rzeszutek Wilk 提交于
      The git commit  1ff2b0c3
      "xen: implement IRQ_WORK_VECTOR handler" added the functionality
      to have a per-cpu "irqworkX" for the IPI APIC functionality.
      However it missed the unbind when a vCPU is unplugged resulting
      in an orphaned per-cpu interrupt line for unplugged vCPU:
      
        30:        216          0   xen-dyn-event     hvc_console
        31:        810          4   xen-dyn-event     eth0
        32:         29          0   xen-dyn-event     blkif
      - 36:          0          0  xen-percpu-ipi       irqwork2
      - 37:        287          0   xen-dyn-event     xenbus
      + 36:        287          0   xen-dyn-event     xenbus
       NMI:          0          0   Non-maskable interrupts
       LOC:          0          0   Local timer interrupts
       SPU:          0          0   Spurious interrupts
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2f1bd67d
  8. 08 5月, 2012 2 次提交
  9. 27 4月, 2012 1 次提交
    • K
      xen/smp: Fix crash when booting with ACPI hotplug CPUs. · cf405ae6
      Konrad Rzeszutek Wilk 提交于
      When we boot on a machine that can hotplug CPUs and we
      are using 'dom0_max_vcpus=X' on the Xen hypervisor line
      to clip the amount of CPUs available to the initial domain,
      we get this:
      
      (XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
      .. snip..
      DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
      .. snip.
      SMP: Allowing 64 CPUs, 32 hotplug CPUs
      installing Xen timer for CPU 7
      cpu 7 spinlock event irq 361
      NMI watchdog: disabled (cpu7): hardware events not enabled
      Brought up 8 CPUs
      .. snip..
      	[acpi processor finds the CPUs are not initialized and starts calling
      	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
      CPU 8 got hotplugged
      CPU 9 got hotplugged
      CPU 10 got hotplugged
      .. snip..
      initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
      calling  erst_init+0x0/0x2bb @ 1
      
      	[and the scheduler sticks newly started tasks on the new CPUs, but
      	said CPUs cannot be initialized b/c the hypervisor has limited the
      	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
      	The spinlock tries to kick the other CPU, but the structure for that
      	is not initialized and we crash.]
      BUG: unable to handle kernel paging request at fffffffffffffed8
      IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
      PGD 180d067 PUD 180e067 PMD 0
      Oops: 0002 [#1] SMP
      CPU 7
      Modules linked in:
      
      Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
      RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
      RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282
      
      With this patch, we cap the amount of vCPUS that the initial domain
      can run, to exactly what dom0_max_vcpus=X has specified.
      
      In the future, if there is a hypercall that will allow a running
      domain to expand past its initial set of vCPUS, this patch should
      be re-evaluated.
      
      CC: stable@kernel.org
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      cf405ae6
  10. 26 4月, 2012 2 次提交
  11. 07 4月, 2012 1 次提交
  12. 22 3月, 2012 1 次提交
    • K
      xen/smp: Fix bringup bug in AP code. · 106b4438
      Konrad Rzeszutek Wilk 提交于
      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: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      106b4438
  13. 04 2月, 2012 1 次提交
    • K
      xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic. · 41bd956d
      Konrad Rzeszutek Wilk 提交于
      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_and_idle:
       \- 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: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      41bd956d
  14. 25 1月, 2012 1 次提交
  15. 09 9月, 2011 1 次提交
  16. 02 9月, 2011 1 次提交
  17. 22 8月, 2011 1 次提交
  18. 16 6月, 2011 1 次提交
    • A
      xen: support CONFIG_MAXSMP · 900cba88
      Andrew Jones 提交于
      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: NAndrew Jones <drjones@redhat.com>
      [v2: Updated to compile on 3.0]
      [v3: Updated to compile when CONFIG_SMP is not defined]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      900cba88
  19. 19 5月, 2011 1 次提交
  20. 14 4月, 2011 1 次提交
  21. 26 2月, 2011 1 次提交
  22. 27 10月, 2010 1 次提交
    • S
      xen: initialize cpu masks for pv guests in xen_smp_init · ea5b8f73
      Stefano Stabellini 提交于
      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
      xen_smp_init.
      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
      xen_setup_vcpu_info_placement.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      ea5b8f73
  23. 23 10月, 2010 1 次提交
  24. 22 10月, 2010 1 次提交
    • A
      x86, kexec: Make sure to stop all CPUs before exiting the kernel · 76fac077
      Alok Kataria 提交于
      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: NAlok 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: NH. Peter Anvin <hpa@linux.intel.com>
      76fac077
  25. 05 8月, 2010 1 次提交
  26. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      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.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      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
        file.
      
      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
         files.
      
      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
         necessary.
      
      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: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  27. 05 2月, 2010 1 次提交
  28. 04 12月, 2009 1 次提交
  29. 04 11月, 2009 1 次提交
  30. 29 10月, 2009 1 次提交
    • T
      percpu: make percpu symbols in xen unique · c6e22f9e
      Tejun Heo 提交于
      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: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      c6e22f9e
  31. 10 9月, 2009 1 次提交
    • J
      xen: make -fstack-protector work under Xen · 577eebea
      Jeremy Fitzhardinge 提交于
      -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: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      577eebea
  32. 09 4月, 2009 1 次提交
  33. 31 3月, 2009 1 次提交
  34. 13 3月, 2009 1 次提交
  35. 02 3月, 2009 1 次提交
    • J
      xen: deal with virtually mapped percpu data · 9976b39b
      Jeremy Fitzhardinge 提交于
      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: NJeremy 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: NIngo Molnar <mingo@elte.hu>
      9976b39b
  36. 05 2月, 2009 1 次提交
  37. 31 1月, 2009 1 次提交
  38. 27 1月, 2009 1 次提交