summaryrefslogtreecommitdiffstats
path: root/drivers/xen/xen-acpi-processor.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* cpuidle / ACPI : remove power from acpi_processor_cx structureDaniel Lezcano2012-09-051-1/+0
| | | | | | | | | | Remove the unused power field from struct struct acpi_processor_cx. [rjw: Modified changelog.] Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* xen/acpi: Fix potential memory leak.Konrad Rzeszutek Wilk2012-07-191-3/+6
| | | | | | | | | Coverity points out that we do not free in one case the pr_backup - and sure enough we forgot. Found by Coverity (CID 401970) Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
* xen-acpi-processor: Add missing #include <xen/xen.h>H. Peter Anvin2012-05-171-0/+1
| | | | | | | | | | | | | | This file depends on <xen/xen.h>, but the dependency was hidden due to: <asm/acpi.h> -> <asm/trampoline.h> -> <asm/io.h> -> <xen/xen.h> With the removal of <asm/trampoline.h>, this exposed the missing Reported-by: Ingo Molnar <mingo@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* xen/acpi: Workaround broken BIOSes exporting non-existing C-states.Konrad Rzeszutek Wilk2012-04-271-1/+4
| | | | | | | | | | | We did a similar check for the P-states but did not do it for the C-states. What we want to do is ignore cases where the DSDT has definition for sixteen CPUs, but the machine only has eight CPUs and we get: xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14 Reported-by: Tobias Geiger <tobias.geiger@vido.info> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
* xen/acpi: Remove the WARN's as they just create noise.Konrad Rzeszutek Wilk2012-03-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
* xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.Konrad Rzeszutek Wilk2012-03-141-0/+562
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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>