>>> On 25.06.18 at 12:17, wrote:
> 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@xxxxxxxx>
> ---
> drivers/acpi/processor_core.c | 1 +
> drivers/xen/xen-acpi-processor.c | 6 ++++++
> 2 files changed, 7 insertions(+)
With Jürgen's R-b in place, may I ask for an ack for the processor_core.c
change, or - in case you dislike the new export - an alternative suggestion?
Thanks, Jan
> --- 4.18-rc2/drivers/acpi/processor_core.c
> +++ 4.18-rc2-xen-ACPI-processor-skip-disabled/drivers/acpi/processor_core.c
> @@ -205,6 +205,7 @@ phys_cpuid_t acpi_get_phys_id(acpi_handl
>
> return phys_id;
> }
> +EXPORT_SYMBOL_GPL(acpi_get_phys_id);
>
> int acpi_map_cpuid(phys_cpuid_t phys_id, u32 acpi_id)
> {
> --- 4.18-rc2/drivers/xen/xen-acpi-processor.c
> +++
> 4.18-rc2-xen-ACPI-processor-skip-disabled/drivers/xen/xen-acpi-processor.c
> @@ -362,6 +362,12 @@ read_acpi_id(acpi_handle handle, u32 lvl
> default:
> return AE_OK;
> }
> + if (invalid_phys_cpuid(acpi_get_phys_id(handle,
> + acpi_type == ACPI_TYPE_DEVICE,
> + acpi_id))) {
> + pr_debug("CPU with ACPI ID %u is unavailable\n", acpi_id);
> + return AE_OK;
> + }
> /* There are more ACPI Processor objects than in x2APIC or MADT.
> * This can happen with incorrect ACPI SSDT declerations. */
> if (acpi_id >= nr_acpi_bits) {
>
>
>
>
