Skip to content
Snippets Groups Projects
  1. Jan 13, 2010
    • Ian Campbell's avatar
      xen: fix hang on suspend. · c5cae661
      Ian Campbell authored
      
      In 65f63384 "xen: improve error handling in do_suspend" I said:
          - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
            nested in the obvious way.
      and changed the ordering of the calls as so:
          BEFORE		AFTER
          xs_suspend		dpm_suspend_noirq
          dpm_suspend_noirq	xs_suspend
          *SUSPEND*		*SUSPEND*
          dpm_resume_noirq	dpm_resume_noirq
          xs_resume		xs_resume
      Clearly this is not an improvement and I was talking rubbish.
      
      In particular the new ordering is susceptible to a hang if a xenstore write is
      in progress at the point at which the suspend kicks in. When the suspend
      process calls xs_suspend it tries to take the request_mutex but if a write is
      in progress it could be looping in xenbus_xs.c:read_reply() waiting for
      something to arrive on &xs_state.reply_list while holding the request_mutex
      (taken in the caller of read_reply).
      
      However if we have done dpm_suspend_noirq before xs_suspend then we won't get
      any more xenstore interrupts and process_msg() will never be woken up to add
      anything to the reply_list.
      
      Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
      fails then make sure we go through the xs_suspend_cancel() code path.
      
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stable Kernel <stable@kernel.org>
      c5cae661
  2. Dec 04, 2009
    • Ian Campbell's avatar
      xen: try harder to balloon up under memory pressure. · bc2c0303
      Ian Campbell authored
      
      Currently if the balloon driver is unable to increase the guest's
      reservation it assumes the failure was due to reaching its full
      allocation, gives up on the ballooning operation and records the limit
      it reached as the "hard limit". The driver will not try again until
      the target is set again (even to the same value).
      
      However it is possible that ballooning has in fact failed due to
      memory pressure in the host and therefore it is desirable to keep
      attempting to reach the target in case memory becomes available. The
      most likely scenario is that some guests are ballooning down while
      others are ballooning up and therefore there is temporary memory
      pressure while things stabilise. You would not expect a well behaved
      toolstack to ask a domain to balloon to more than its allocation nor
      would you expect it to deliberately over-commit memory by setting
      balloon targets which exceed the total host memory.
      
      This patch drops the concept of a hard limit and causes the balloon
      driver to retry increasing the reservation on a timer in the same
      manner as when decreasing the reservation.
      
      Also if we partially succeed in increasing the reservation
      (i.e. receive less pages than we asked for) then we may as well keep
      those pages rather than returning them to Xen.
      
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Cc: Stable Kernel <stable@kernel.org>
      bc2c0303
    • Gianluca Guida's avatar
      Xen balloon: fix totalram_pages counting. · 3d65c948
      Gianluca Guida authored
      
      Change totalram_pages when a single page is added/removed to the
      ballooned list. This avoid totalram_pages to be set erroneously to
      max_pfn at boot.
      
      Signed-off-by: default avatarGianluca Guida <gianluca.guida@citrix.com>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stable Kernel <stable@kernel.org>
      3d65c948
  3. Dec 03, 2009
  4. Nov 04, 2009
  5. Oct 04, 2009
  6. Sep 22, 2009
  7. Sep 21, 2009
  8. Sep 20, 2009
  9. Sep 09, 2009
    • 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>
      577eebea
  10. Jul 01, 2009
    • Pekka Enberg's avatar
      xen: Use kcalloc() in xen_init_IRQ() · a70c352a
      Pekka Enberg authored
      
      The init_IRQ() function is now called with slab allocator initialized.
      Therefore, we must not use the bootmem allocator in xen_init_IRQ().
      
      Fixes the following boot-time warning:
      
        ------------[ cut here ]------------
        WARNING: at mm/bootmem.c:535 alloc_arch_preferred_bootmem+0x27/0x45()
        Modules linked in:
        Pid: 0, comm: swapper Not tainted 2.6.30 #1
        Call Trace:
         [<ffffffff8102d6e3>] ? warn_slowpath_common+0x73/0xb0
         [<ffffffff810210d9>] ? pvclock_clocksource_read+0x49/0x90
         [<ffffffff812e522f>] ? alloc_arch_preferred_bootmem+0x27/0x45
         [<ffffffff812e5761>] ? ___alloc_bootmem_nopanic+0x39/0xc9
         [<ffffffff812e57fa>] ? ___alloc_bootmem+0x9/0x2f
         [<ffffffff812e9e21>] ? xen_init_IRQ+0x25/0x61
         [<ffffffff812d69ee>] ? start_kernel+0x1b5/0x29e
        ---[ end trace 4eaa2a86a8e2da22 ]---
      
      Acked-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Tested-by: default avatarChristian Kujau <lists@nerdbynature.de>
      Reported-by: default avatarChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: lists@nerdbynature.de
      Cc: jeremy.fitzhardinge@citrix.com
      LKML-Reference: <1246438278.22417.28.camel@penberg-laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a70c352a
  11. Jun 24, 2009
    • Tejun Heo's avatar
      percpu: clean up percpu variable definitions · 245b2e70
      Tejun Heo authored
      
      Percpu variable definition is about to be updated such that all percpu
      symbols including the static ones must be unique.  Update percpu
      variable definitions accordingly.
      
      * as,cfq: rename ioc_count uniquely
      
      * cpufreq: rename cpu_dbs_info uniquely
      
      * xen: move nesting_count out of xen_evtchn_do_upcall() and rename it
      
      * mm: move ratelimits out of balance_dirty_pages_ratelimited_nr() and
        rename it
      
      * ipv4,6: rename cookie_scratch uniquely
      
      * x86 perf_counter: rename prev_left to pmc_prev_left, irq_entry to
        pmc_irq_entry and nmi_entry to pmc_nmi_entry
      
      * perf_counter: rename disable_count to perf_disable_count
      
      * ftrace: rename test_event_disable to ftrace_test_event_disable
      
      * kmemleak: rename test_pointer to kmemleak_test_pointer
      
      * mce: rename next_interval to mce_next_interval
      
      [ Impact: percpu usage cleanups, no duplicate static percpu var names ]
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      245b2e70
    • Tejun Heo's avatar
      percpu: cleanup percpu array definitions · 204fba4a
      Tejun Heo authored
      
      Currently, the following three different ways to define percpu arrays
      are in use.
      
      1. DEFINE_PER_CPU(elem_type[array_len], array_name);
      2. DEFINE_PER_CPU(elem_type, array_name[array_len]);
      3. DEFINE_PER_CPU(elem_type, array_name)[array_len];
      
      Unify to #1 which correctly separates the roles of the two parameters
      and thus allows more flexibility in the way percpu variables are
      defined.
      
      [ Impact: cleanup ]
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm@kvack.org
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      204fba4a
  12. Jun 12, 2009
    • Alan Stern's avatar
      PM core: rename suspend and resume functions · d1616302
      Alan Stern authored
      
      This patch (as1241) renames a bunch of functions in the PM core.
      Rather than go through a boring list of name changes, suffice it to
      say that in the end we have a bunch of pairs of functions:
      
      	device_resume_noirq	dpm_resume_noirq
      	device_resume		dpm_resume
      	device_complete		dpm_complete
      	device_suspend_noirq	dpm_suspend_noirq
      	device_suspend		dpm_suspend
      	device_prepare		dpm_prepare
      
      in which device_X does the X operation on a single device and dpm_X
      invokes device_X for all devices in the dpm_list.
      
      In addition, the old dpm_power_up and device_resume_noirq have been
      combined into a single function (dpm_resume_noirq).
      
      Lastly, dpm_suspend_start and dpm_resume_end are the renamed versions
      of the former top-level device_suspend and device_resume routines.
      
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarMagnus Damm <damm@igel.co.jp>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      d1616302
    • Magnus Damm's avatar
      PM: Rename device_power_down/up() · e39a71ef
      Magnus Damm authored
      
      Rename the functions performing "_noirq" dev_pm_ops
      operations from device_power_down() and device_power_up()
      to device_suspend_noirq() and device_resume_noirq().
      
      The new function names are chosen to show that the functions
      are responsible for calling the _noirq() versions to finalize
      the suspend/resume operation. The current function names do
      not perform power down/up anymore so the names may be misleading.
      
      Global function renames:
      - device_power_down() -> device_suspend_noirq()
      - device_power_up() -> device_resume_noirq()
      
      Static function renames:
      - suspend_device_noirq() -> __device_suspend_noirq()
      - resume_device_noirq() -> __device_resume_noirq()
      
      Signed-off-by: default avatarMagnus Damm <damm@igel.co.jp>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: default avatarLen Brown <lenb@kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      e39a71ef
  13. May 05, 2009
  14. Apr 28, 2009
    • Yinghai Lu's avatar
      x86/irq: change irq_desc_alloc() to take node instead of cpu · 85ac16d0
      Yinghai Lu authored
      
      This simplifies the node awareness of the code. All our allocators
      only deal with a NUMA node ID locality not with CPU ids anyway - so
      there's no need to maintain (and transform) a CPU id all across the
      IRq layer.
      
      v2: keep move_irq_desc related
      
      [ Impact: cleanup, prepare IRQ code to be NUMA-aware ]
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      LKML-Reference: <49F65536.2020300@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      85ac16d0
    • Yinghai Lu's avatar
      irq: change ->set_affinity() to return status · d5dedd45
      Yinghai Lu authored
      
      according to Ingo, change set_affinity() in irq_chip should return int,
      because that way we can handle failure cases in a much cleaner way, in
      the genirq layer.
      
      v2: fix two typos
      
      [ Impact: extend API ]
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: linux-arch@vger.kernel.org
      LKML-Reference: <49F654E9.4070809@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d5dedd45
  15. Apr 08, 2009
  16. Apr 02, 2009
    • Ian Campbell's avatar
      xen: honour VCPU availability on boot · 53152f95
      Ian Campbell authored
      
      If a VM is booted with offline VCPUs then unplug them during boot. Determining
      the availability of a VCPU requires access to XenStore which is not available
      at the point smp_prepare_cpus() is called, therefore we bring up all VCPUS
      initially and unplug the offline ones as soon as XenStore becomes available.
      
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      53152f95
  17. Mar 30, 2009
Loading