| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <DE8DF0795D48FD4CA783C40EC82923359737@SHSMSX101.ccr.corp.intel.com>
Date: Fri, 23 Dec 2011 10:30:48 +0000
From: "Liu, Jinsong" <jinsong.liu@...el.com>
To: "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
CC: "Jiang, Yunhong" <yunhong.jiang@...el.com>,
"jeremy.fitzhardinge@...rix.com" <jeremy.fitzhardinge@...rix.com>,
"Shan, Haitao" <haitao.shan@...el.com>,
"Zhao, Yakui" <yakui.zhao@...el.com>,
"Brown, Len" <len.brown@...el.com>,
"Luck, Tony" <tony.luck@...el.com>,
"Kleen, Andi" <andi.kleen@...el.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
>From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@...el.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundant.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.
This patch also add Xen PPC handle when cpu hotadd.
Signed-off-by: Liu, Jinsong <jinsong.liu@...el.com>
---
drivers/acpi/processor_xen.c | 103 +++++++++++++++++++++++-------------------
1 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_device *device)
return 0;
}
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr)
+{
+ acpi_status status = 0;
+ unsigned long long ppc = 0;
+
+ if (!pr)
+ return -EINVAL;
+
+ /*
+ * _PPC indicates the maximum state currently supported by the platform
+ * (e.g. 0 = states 0..n; 1 = states 1..n; etc.
+ */
+ status = acpi_evaluate_integer(pr->handle, "_PPC", NULL, &ppc);
+
+ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+ ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+ return -ENODEV;
+ }
+
+ pr->performance_platform_limit = (int)ppc;
+
+ return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+ int ret;
+
+ ret = xen_acpi_processor_get_platform_limit(pr);
+
+ if (ret < 0)
+ return ret;
+ else
+ return processor_cntl_xen_notify(pr,
+ PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor *pr,
+ struct acpi_device *device)
+{
+ if (likely(!pr->flags.power_setup_done)) {
+ /* reset idle boot option which we don't care */
+ boot_option_idle_override = IDLE_NO_OVERRIDE;
+ acpi_processor_power_init(pr, device);
+ /* set to IDLE_HALT for trapping into Xen */
+ boot_option_idle_override = IDLE_HALT;
+
+ if (pr->flags.power)
+ processor_cntl_xen_notify(pr,
+ PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+ }
+}
+
static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
{
struct acpi_processor *pr = NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
}
#ifdef CONFIG_CPU_FREQ
- acpi_processor_ppc_has_changed(pr, 0);
+ xen_acpi_processor_ppc_has_changed(pr);
#endif
acpi_processor_get_throttling_info(pr);
acpi_processor_get_limit_info(pr);
-
- if (cpuidle_get_driver() == &acpi_idle_driver)
- acpi_processor_power_init(pr, device);
+ xen_acpi_processor_power_init(pr, device);
pr->cdev = thermal_cooling_device_register("Processor", device,
&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
if (!pr)
return -EINVAL;
- if (pr->id == -1) {
- int device_declaration;
- int apic_id = -1;
-
- if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
- device_declaration = 0;
- else
- device_declaration = 1;
-
- apic_id = acpi_get_cpuid(pr->handle,
- device_declaration, pr->acpi_id);
- if (apic_id == -1) {
- /* Processor is not present in MADT table */
- return 0;
- }
-
- /*
- * It's possible to have pr->id as '-1' even when it's actually
- * present in MADT table, e.g. due to limiting dom0 max vcpus
- * less than physical present number. In such case we still want
- * to parse ACPI processor object information, so mimic the
- * pr->id to CPU-0. This should be safe because we only care
- * about raw ACPI information, which only relies on pr->acpi_id.
- * For other information relying on pr->id and gathered through
- * SMP function call, it's safe to let them run on CPU-0 since
- * underlying Xen will collect them. Only a valid pr->id can
- * make later invocations forward progress.
- */
- pr->id = 0;
- }
-
- if (likely(!pr->flags.power_setup_done)) {
- /* reset idle boot option which we don't care */
- boot_option_idle_override = IDLE_NO_OVERRIDE;
- acpi_processor_power_init(pr, device);
- /* set to IDLE_HALT for trapping into Xen */
- boot_option_idle_override = IDLE_HALT;
-
- if (pr->flags.power)
- processor_cntl_xen_notify(pr,
- PROCESSOR_PM_INIT, PM_TYPE_IDLE);
- }
+ if (pr->id == -1)
+ return 0;
#ifdef CONFIG_CPU_FREQ
if (likely(!pr->performance))
--
1.6.5.6
Download attachment "0009-xen-acpi-Change-Cx-notify-and-add-PPC-handle.patch" of type "application/octet-stream" (4832 bytes)
Powered by blists - more mailing lists