1. 15 3月, 2012 2 次提交
    • K
      xen/acpi-processor: C and P-state driver that uploads said data to hypervisor. · 59a56802
      Konrad Rzeszutek Wilk 提交于
      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: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      59a56802
    • J
      xen: constify all instances of "struct attribute_group" · ead1d014
      Jan Beulich 提交于
      The functions these get passed to have been taking pointers to const
      since at least 2.6.16.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ead1d014
  2. 14 3月, 2012 5 次提交
  3. 27 2月, 2012 1 次提交
  4. 13 1月, 2012 2 次提交
  5. 12 1月, 2012 2 次提交
  6. 11 1月, 2012 28 次提交