Xen devel - May 2012 - [PATCH 1/2] Export acpi_processor_set_pdc to modules.

The Xen ACPI module calls acpi_processor_set_pdc for ACPI IDs
for CPUs that are not visible to an instance of a running Linux
kernel. Meaning it calls them on the ones that the generic
code has no control over. But without this being exported
the module will fail to compile.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_core.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index c850de4..7c7c2d9 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -352,6 +352,7 @@ void __cpuinit acpi_processor_set_pdc(acpi_handle handle)
 	kfree(obj_list->pointer);
 	kfree(obj_list);
 }
+EXPORT_SYMBOL_GPL(acpi_processor_set_pdc);
 
 static acpi_status __init
 early_init_pdc(acpi_handle handle, u32 lvl, void *context, void **rv)
-- 
1.7.7.5

acpi_early_processor_set_pdc does this (executes _PDC), but it
cannot do it for vCPUS that are past the currently available vCPUS
(so dom0_max_vcpus=X is used). We can easily find if that is
the case by seeing if we get the same failure as the generic code
and if so run _PDC ourselves. We also (by doing some other hypercalls)
know how many physical CPUs there are - which the acpi_get_cpuid
can''t - as it bands the amount of CPUs up to
''cpu_possible()''
which has been influenced by ''dom0_max_vcpus=X'' flag.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-acpi-processor.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
index 0b48579..bb9f711 100644
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -323,7 +323,7 @@ static unsigned int __init get_max_acpi_id(void)
 /*
  * The read_acpi_id and check_acpi_ids are there to support the Xen
  * oddity of virtual CPUs != physical CPUs in the initial domain.
- * The user can supply ''xen_max_vcpus=X'' on the Xen
hypervisor line
+ * The user can supply ''dom0_max_vcps=X'' on the Xen
hypervisor line
  * which will band the amount of CPUs the initial domain can see.
  * In general that is OK, except it plays havoc with any of the
  * for_each_[present|online]_cpu macros which are banded to the virtual
@@ -374,6 +374,14 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context,
void **rv)
 	pr_debug(DRV_NAME "ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id,
 		 (unsigned long)pblk);
 
+	/* acpi_early_processor_set_pdc does this, but it cannot do it for vCPUS
+	 * that are past the currently available vCPUS (so dom0_max_vcpus=X is
+	 * used). We can easily find if that is the case by seeing if we get the
+	 * same failure as the generic code and if so run _PDC ourselves.
+	 */
+	if (acpi_get_cpuid(handle, (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0, acpi_id)
== -1)
+		acpi_processor_set_pdc(handle);
+
 	status = acpi_evaluate_object(handle, "_CST", NULL, &buffer);
 	if (ACPI_FAILURE(status)) {
 		if (!pblk)
-- 
1.7.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html