summaryrefslogtreecommitdiff
path: root/drivers/xen/xen-acpi-processor.c
AgeCommit message (Collapse)Author
2019-03-04xen/ACPI: Switch to bitmap_zalloc()Andy Shevchenko
Switch to bitmap_zalloc() to show clearly what we are allocating. Besides that it returns pointer of bitmap type instead of opaque void *. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-08-20xen/ACPI: don't upload Px/Cx data for disabled processorsJan Beulich
This is unnecessary and triggers a warning in the hypervisor. Often systems have more processor entries in their ACPI tables than are actually installed/active. The ACPI_STA_DEVICE_PRESENT bit cannot be reliably used, but the ACPI_MADT_ENABLED bit can. In order to not introduce new functions in the main ACPI processor driver code, simply use acpi_get_phys_id(), which does more than we need, but which checks the MADT enabled bit in the process. Any CPU for which we can't determine the APIC ID is unlikely to work properly anyway, so the extra checks done by acpi_get_phys_id() should do no harm. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-03-30xen/acpi: off by one in read_acpi_id()Dan Carpenter
If acpi_id is == nr_acpi_bits, then we access one element beyond the end of the acpi_psd[] array or we set one bit beyond the end of the bit map when we do __set_bit(acpi_id, acpi_id_present); Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-03-21xen/acpi: upload _PSD info for non Dom0 CPUs tooJoao Martins
All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore any cpufreq domains created for past CPUs. Albeit for platforms which expose coordination types as SW_ANY or SW_ALL, this will have some unintended side effects. Effectively, it will look at the P-state domain existence and *if it already exists* it will skip the acpi-cpufreq initialization and thus inherit the policy from the first CPU in the cpufreq domain. This will finally lead to the original cpu not changing target freq to P0 other than the first in the domain. Which will make turbo boost not getting enabled (e.g. for 'performance' governor) for all cpus. This patch fixes that, by also evaluating _PSD when we enumerate all ACPI processors and thus always uploading the correct info to Xen. We export acpi_processor_get_psd() for that this purpose, but change signature to not assume an existent of acpi_processor given that ACPI isn't creating an acpi_processor for non-dom0 CPUs. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2017-03-23xen/acpi: upload PM state from init-domain to XenAnkur Arora
This was broken in commit cd979883b9ed ("xen/acpi-processor: fix enabling interrupts on syscore_resume"). do_suspend (from xen/manage.c) and thus xen_resume_notifier never get called on the initial-domain at resume (it is if running as guest.) The rationale for the breaking change was that upload_pm_data() potentially does blocking work in syscore_resume(). This patch addresses the original issue by scheduling upload_pm_data() to execute in workqueue context. Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: stable@vger.kernel.org Based-on-patch-by: Konrad Wilk <konrad.wilk@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2017-03-23xen/acpi: Replace hard coded "ACPI0007"Ankur Arora
Replace hard coded "ACPI0007" with ACPI_PROCESSOR_DEVICE_HID Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2016-07-08xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7Jan Beulich
As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on both Intel and AMD systems. Doing any kind of hardware capability checks in the driver as a prerequisite was wrong anyway: With the hypervisor being in charge, all such checking should be done by it. If ACPI data gets uploaded despite some missing capability, the hypervisor is free to ignore part or all of that data. Ditch the entire check_prereq() function, and do the only valid check (xen_initial_domain()) in the caller in its place. Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
2015-12-21xen: rename dom0_op to platform_opStefano Stabellini
The dom0_op hypercall has been renamed to platform_op since Xen 3.2, which is ancient, and modern upstream Linux kernels cannot run as dom0 and it anymore anyway. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2015-07-22ACPI / processor: Drop an unused argument of a cleanup routineRafael J. Wysocki
acpi_processor_unregister_performance() actually doesn't use its first argument, so drop it and update the callers accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2014-05-23xen-acpi-processor: Don't display errors when we get -ENOSYSKonrad Rzeszutek Wilk
which is a perfectly legal error. This can be triggered if the user has booted Xen with the no-cpuidle parameter. Reported-by-and-Tested-by: Don Slutz <dslutz@verizon.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2014-03-18xen/acpi-processor: fix enabling interrupts on syscore_resumeStanislaw Gruszka
syscore->resume() callback is expected to do not enable interrupts, it generates warning like below otherwise: [ 9386.365390] WARNING: CPU: 0 PID: 6733 at drivers/base/syscore.c:104 syscore_resume+0x9a/0xe0() [ 9386.365403] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor] ... [ 9386.365429] Call Trace: [ 9386.365434] [<ffffffff81667a8b>] dump_stack+0x45/0x56 [ 9386.365437] [<ffffffff8106921d>] warn_slowpath_common+0x7d/0xa0 [ 9386.365439] [<ffffffff8106928c>] warn_slowpath_fmt+0x4c/0x50 [ 9386.365442] [<ffffffffa0261bb0>] ? xen_upload_processor_pm_data+0x300/0x300 [xen_acpi_processor] [ 9386.365443] [<ffffffff814055fa>] syscore_resume+0x9a/0xe0 [ 9386.365445] [<ffffffff810aef42>] suspend_devices_and_enter+0x402/0x470 [ 9386.365447] [<ffffffff810af128>] pm_suspend+0x178/0x260 On xen_acpi_processor_resume() we call various procedures, which are non atomic and can enable interrupts. To prevent the issue introduce separate resume notify called after we enable interrupts on resume and before we call other drivers resume callbacks. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-12-07ACPI: Clean up inclusions of ACPI header filesLv Zheng
Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-28xen: Convert printks to pr_<level>Joe Perches
Convert printks to pr_<level> (excludes printk(KERN_DEBUG...) to be more consistent throughout the xen subsystem. Add pr_fmt with KBUILD_MODNAME or "xen:" KBUILD_MODNAME Coalesce formats and add missing word spaces Add missing newlines Align arguments and reflow to 80 columns Remove DRV_NAME from formats as pr_fmt adds the same content This does change some of the prefixes of these messages but it also does make them more consistent. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-04-19xen: resolve section mismatch warnings in xen-acpi-processorBen Guthro
The following resolves a section mismatch warning below in xen-acpi-processor introduced by 3fac10145b766a2244422788f62dc35978613fd8 [13/13] xen: Re-upload processor PM data to hypervisor after S3 resume (v2) Warning: WARNING: drivers/xen/built-in.o(.text+0x2056a): Section mismatch in reference from the function xen_upload_processor_pm_data() to the function .init.text:read_acpi_id() The function xen_upload_processor_pm_data() references the function __init read_acpi_id(). This is often because xen_upload_processor_pm_data lacks a __init annotation or the annotation of read_acpi_id is wrong. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-04-17xen: Re-upload processor PM data to hypervisor after S3 resume (v2)Ben Guthro
Upon resume, it was found that ACPI C-states were missing from non-boot CPUs. This change registers a syscore_ops handler for this case, and re-uploads the PM information to the hypervisor to properly reset the C-state on these processors. v2: v1 did not go through the check_acpi_ids() code-path, and missed some cases when xen was running with the dom0_max_vcpus= command line parameter. Signed-Off-By: Ben Guthro <benjamin.guthro@citrix.com> [v3: Ate some tabs, s/printk/pr_info/] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-22xen/acpi-processor: Don't dereference struct acpi_processor on all CPUs.Konrad Rzeszutek Wilk
With git commit c705c78c0d0835a4aa5d0d9a3422e3218462030c "acpi: Export the acpi_processor_get_performance_info" we are now using a different mechanism to access the P-states. The acpi_processor per-cpu structure is set and filtered by the core ACPI code which shrinks the per_cpu contents to only online CPUs. In the past we would call acpi_processor_register_performance() which would have not tried to dereference offline cpus. With the new patch and the fact that the loop we take is for for_all_possible_cpus we end up crashing on some machines. We could modify the loop to be for online_cpus - but all the other loops in the code use possible_cpus (for a good reason) - so lets leave it as so and just check if per_cpu(processor) is NULL. With this patch we will bypass the !online but possible CPUs. This fixes: IP: [<ffffffffa00d13b5>] xen_acpi_processor_init+0x1b6/0xe01 [xen_acpi_processor] PGD 4126e6067 PUD 4126e3067 PMD 0 Oops: 0002 [#1] SMP Pid: 432, comm: modprobe Not tainted 3.9.0-rc3+ #28 To be filled by O.E.M. To be filled by O.E.M./M5A97 RIP: e030:[<ffffffffa00d13b5>] [<ffffffffa00d13b5>] xen_acpi_processor_init+0x1b6/0xe01 [xen_acpi_processor] RSP: e02b:ffff88040c8a3ce8 EFLAGS: 00010282 .. snip.. Call Trace: [<ffffffffa00d11ff>] ? read_acpi_id+0x12b/0x12b [xen_acpi_processor] [<ffffffff8100215a>] do_one_initcall+0x12a/0x180 [<ffffffff810c42c3>] load_module+0x1cd3/0x2870 [<ffffffff81319b70>] ? ddebug_proc_open+0xc0/0xc0 [<ffffffff810c4f37>] sys_init_module+0xd7/0x120 [<ffffffff8166ce19>] system_call_fastpath+0x16/0x1b on some machines. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-03-06acpi: Export the acpi_processor_get_performance_infoKonrad Rzeszutek Wilk
The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8 (cpufreq: handle cpufreq being disabled for all exported function) tightens the cpufreq API by returning errors when disable_cpufreq() had been called. The problem we are hitting is that the module xen-acpi-processor which uses the ACPI's functions: acpi_processor_register_performance, acpi_processor_preregister_performance, and acpi_processor_notify_smm fails at acpi_processor_register_performance with -22. Note that earlier during bootup in arch/x86/xen/setup.c there is also an call to cpufreq's API: disable_cpufreq(). This is b/c we want the Linux kernel to parse the ACPI data, but leave the cpufreq decisions to the hypervisor. In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8 added are now hit and the calls to cpufreq_register_notifier will now fail. This means that acpi_processor_ppc_init ends up printing: "Warning: Processor Platform Limit not supported" and the acpi_processor_ppc_status is not set. The repercussions of that is that the call to acpi_processor_register_performance fails right away at: if (!(acpi_processor_ppc_status & PPC_REGISTERED)) and we don't progress any further on parsing and extracting the _P* objects. The only reason the Xen code called that function was b/c it was exported and the only way to gather the P-states. But we can also just make acpi_processor_get_performance_info be exported and not use acpi_processor_register_performance. This patch does so. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-09-05cpuidle / ACPI : remove power from acpi_processor_cx structureDaniel Lezcano
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>
2012-07-19xen/acpi: Fix potential memory leak.Konrad Rzeszutek Wilk
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>
2012-05-17xen-acpi-processor: Add missing #include <xen/xen.h>H. Peter Anvin
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>
2012-04-26xen/acpi: Workaround broken BIOSes exporting non-existing C-states.Konrad Rzeszutek Wilk
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>
2012-03-21xen/acpi: Remove the WARN's as they just create noise.Konrad Rzeszutek Wilk
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>
2012-03-14xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>