[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1335893094-6904-2-git-send-email-konrad.wilk@oracle.com>
Date: Tue, 1 May 2012 13:24:54 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: lenb@...nel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: xen-devel@...ts.xensource.com,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: [PATCH 2/2] xen/acpi: Execute _PDC on CPUs past the ones seen to the guest.
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@...cle.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists