1. 17 Sep, 2012 4 commits
  2. 30 May, 2012 2 commits
  3. 21 May, 2012 3 commits
  4. 17 May, 2012 1 commit
  5. 15 May, 2012 1 commit
  6. 07 May, 2012 3 commits
  7. 27 Apr, 2012 1 commit
  8. 26 Apr, 2012 1 commit
  9. 19 Apr, 2012 2 commits
    • Konrad Rzeszutek Wilk's avatar
      xen/resume: Fix compile warnings. · 186bab1c
      Konrad Rzeszutek Wilk authored
      
      
      linux/drivers/xen/manage.c: In function 'do_suspend':
      linux/drivers/xen/manage.c:160:5: warning: 'si.cancelled' may be used uninitialized in this function
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      186bab1c
    • Konrad Rzeszutek Wilk's avatar
      xen/xenbus: Add quirk to deal with misconfigured backends. · 3066616c
      Konrad Rzeszutek Wilk authored
      
      
      A rather annoying and common case is when booting a PVonHVM guest
      and exposing the PV KBD and PV VFB - as broken toolstacks don't
      always initialize the backends correctly.
      
      Normally The HVM guest is using the VGA driver and the emulated
      keyboard for this (though upstream version of QEMU implements
      PV KBD, but still uses a VGA driver). We provide a very basic
      two-stage wait mechanism - where we wait for 30 seconds for all
      devices, and then for 270 for all them except the two mentioned.
      
      That allows us to wait for the essential devices, like network
      or disk for the full 6 minutes.
      
      To trigger this, put this in your guest config:
      
      vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
      
      instead of this:
      vnc=1
      vnclisten="0.0.0.0"
      
      CC: stable@kernel.org
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      [v3: Split delay in non-essential (30 seconds) and essential
       devices per Ian and Stefano suggestion]
      [v4: Added comments per Stefano suggestion]
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      3066616c
  10. 17 Apr, 2012 3 commits
  11. 16 Apr, 2012 1 commit
  12. 06 Apr, 2012 1 commit
    • Jan Beulich's avatar
      xen/pciback: fix XEN_PCI_OP_enable_msix result · 0ee46eca
      Jan Beulich authored
      
      
      Prior to 2.6.19 and as of 2.6.31, pci_enable_msix() can return a
      positive value to indicate the number of vectors (less than the amount
      requested) that can be set up for a given device. Returning this as an
      operation value (secondary result) is fine, but (primary) operation
      results are expected to be negative (error) or zero (success) according
      to the protocol. With the frontend fixed to match the XenoLinux
      behavior, the backend can now validly return zero (success) here,
      passing the upper limit on the number of vectors in op->value.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      0ee46eca
  13. 28 Mar, 2012 1 commit
  14. 24 Mar, 2012 1 commit
    • Konrad Rzeszutek Wilk's avatar
      xen/acpi: Fix Kconfig dependency on CPU_FREQ · df7a3ee2
      Konrad Rzeszutek Wilk authored
      
      
      The functions: "acpi_processor_*" sound like they depend on CONFIG_ACPI_PROCESSOR
      but in reality they are exposed when CONFIG_CPU_FREQ=[y|m]. As such
      update the Kconfig to have this dependency and fix compile issues:
      
      ERROR: "acpi_processor_unregister_performance" [drivers/xen/xen-acpi-processor.ko] undefined!
      ERROR: "acpi_processor_notify_smm" [drivers/xen/xen-acpi-processor.ko] undefined!
      ERROR: "acpi_processor_register_performance" [drivers/xen/xen-acpi-processor.ko] undefined!
      ERROR: "acpi_processor_preregister_performance" [drivers/xen/xen-acpi-processor.ko] undefined!
      
      Note: We still need the CONFIG_ACPI
      Reported-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      df7a3ee2
  15. 22 Mar, 2012 1 commit
  16. 21 Mar, 2012 1 commit
    • Konrad Rzeszutek Wilk's avatar
      xen/acpi: Remove the WARN's as they just create noise. · 27257fc0
      Konrad Rzeszutek Wilk authored
      
      
      When booting the kernel under machines that do not have P-states
      we would end up with:
      
      ------------[ cut here ]------------
       WARNING: at drivers/xen/xen-acpi-processor.c:504
       xen_acpi_processor_init+0x286/0
       x2e0()
       Hardware name: ProLiant BL460c G6
       Modules linked in:
       Pid: 1, comm: swapper Not tainted 2.6.39-200.0.3.el5uek #1
       Call Trace:
        [<ffffffff8191d056>] ? xen_acpi_processor_init+0x286/0x2e0
        [<ffffffff81068300>] warn_slowpath_common+0x90/0xc0
        [<ffffffff8191cdd0>] ? check_acpi_ids+0x1e0/0x1e0
        [<ffffffff8106834a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff8191d056>] xen_acpi_processor_init+0x286/0x2e0
        [<ffffffff8191cdd0>] ? check_acpi_ids+0x1e0/0x1e0
        [<ffffffff81002168>] do_one_initcall+0xe8/0x130
      
      .. snip..
      
      Which is OK - the machines do not have P-states, so we fail to register
      to process the _PXX states. But there is no need to WARN the user
      of it.
      
      Oracle BZ# 13871288
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      27257fc0
  17. 20 Mar, 2012 3 commits
  18. 14 Mar, 2012 2 commits
    • Konrad Rzeszutek Wilk's avatar
      xen/acpi-processor: C and P-state driver that uploads said data to hypervisor. · 59a56802
      Konrad Rzeszutek Wilk authored
      
      
      This driver solves three problems:
       1). Parse and upload ACPI0007 (or PROCESSOR_TYPE) information to the
           hypervisor - aka P-states (cpufreq data).
       2). Upload the the Cx state information (cpuidle data).
       3). Inhibit CPU frequency scaling drivers from loading.
      
      The reason for wanting to solve 1) and 2) is such that the Xen hypervisor
      is the only one that knows the CPU usage of different guests and can
      make the proper decision of when to put CPUs and packages in proper states.
      Unfortunately the hypervisor has no support to parse ACPI DSDT tables, hence it
      needs help from the initial domain to provide this information. The reason
      for 3) is that we do not want the initial domain to change P-states while the
      hypervisor is doing it as well - it causes rather some funny cases of P-states
      transitions.
      
      For this to work, the driver parses the Power Management data and uploads said
      information to the Xen hypervisor. It also calls acpi_processor_notify_smm()
      to inhibit the other CPU frequency scaling drivers from being loaded.
      
      Everything revolves around the 'struct acpi_processor' structure which
      gets updated during the bootup cycle in different stages. At the startup, when
      the ACPI parser starts, the C-state information is processed (processor_idle)
      and saved in said structure as 'power' element. Later on, the CPU frequency
      scaling driver (powernow-k8 or acpi_cpufreq), would call the the
      acpi_processor_* (processor_perflib functions) to parse P-states information
      and populate in the said structure the 'performance' element.
      
      Since we do not want the CPU frequency scaling drivers from loading
      we have to call the acpi_processor_* functions to parse the P-states and
      call "acpi_processor_notify_smm" to stop them from loading.
      
      There is also one oddity in this driver which is that under Xen, the
      physical online CPU count can be different from the virtual online CPU count.
      Meaning that the macros 'for_[online|possible]_cpu' would process only
      up to virtual online CPU count. We on the other hand want to process
      the full amount of physical CPUs. For that, the driver checks if the ACPI IDs
      count is different from the APIC ID count - which can happen if the user
      choose to use dom0_max_vcpu argument. In such a case a backup of the PM
      structure is used and uploaded to the hypervisor.
      
      [v1-v2: Initial RFC implementations that were posted]
      [v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>]
      [v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
      [v5: Cleaned up the driver, fix bug under Athlon XP]
      [v6: Changed the driver to a CPU frequency governor]
      [v7: Jan Beulich <jbeulich@suse.com> suggestion to make it a cpufreq scaling driver
           made me rework it as driver that inhibits cpufreq scaling driver]
      [v8: Per Jan's review comments, fixed up the driver]
      [v9: Allow to continue even if acpi_processor_preregister_perf.. fails]
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      59a56802
    • Jan Beulich's avatar
      xen: constify all instances of "struct attribute_group" · ead1d014
      Jan Beulich authored
      
      
      The functions these get passed to have been taking pointers to const
      since at least 2.6.16.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ead1d014
  19. 13 Mar, 2012 2 commits
  20. 26 Feb, 2012 1 commit
  21. 14 Feb, 2012 1 commit
  22. 03 Feb, 2012 3 commits
  23. 29 Jan, 2012 1 commit
    • Rafael J. Wysocki's avatar
      PM / Sleep: Introduce "late suspend" and "early resume" of devices · cf579dfb
      Rafael J. Wysocki authored
      
      
      The current device suspend/resume phases during system-wide power
      transitions appear to be insufficient for some platforms that want
      to use the same callback routines for saving device states and
      related operations during runtime suspend/resume as well as during
      system suspend/resume.  In principle, they could point their
      .suspend_noirq() and .resume_noirq() to the same callback routines
      as their .runtime_suspend() and .runtime_resume(), respectively,
      but at least some of them require device interrupts to be enabled
      while the code in those routines is running.
      
      It also makes sense to have device suspend-resume callbacks that will
      be executed with runtime PM disabled and with device interrupts
      enabled in case someone needs to run some special code in that
      context during system-wide power transitions.
      
      Apart from this, .suspend_noirq() and .resume_noirq() were introduced
      as a workaround for drivers using shared interrupts and failing to
      prevent their interrupt handlers from accessing suspended hardware.
      It appears to be better not to use them for other porposes, or we may
      have to deal with some serious confusion (which seems to be happening
      already).
      
      For the above reasons, introduce new device suspend/resume phases,
      "late suspend" and "early resume" (and analogously for hibernation)
      whose callback will be executed with runtime PM disabled and with
      device interrupts enabled and whose callback pointers generally may
      point to runtime suspend/resume routines.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      cf579dfb