"Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes: > On Mon, Feb 6, 2017 at 6:01 PM, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: >> We may or may not have all possible CPUs in MADT on boot but in any case >> we're overwriting x86_cpu_to_acpiid mapping with U32_MAX when >> acpi_register_lapic() is called again on the CPU hotplug path: >> acpi_processor_hotadd_init() -> acpi_map_cpu() -> acpi_register_lapic(). >> >> As we have the required acpi_id information in acpi_processor_hotadd_init() >> propagate it to acpi_map_cpu() to always keep x86_cpu_to_acpiid mapping >> valid. >> >> Reported-by: Andrew Jones <drjones@xxxxxxxxxx> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > > Is the bug report available and if so, do you have a pointer to it? > There was no 'real' bug, the issue was found by code inspection. Potentially, the following scenario is currently broken: - boot Xen HVM guest and do kdump on a secondary CPU - with kdump kernel running try to hot-plug additional CPUs. we'll end up with U32_MAX in x86_cpu_to_acpiid for hot-plugged CPUs so we'll be assuming direct Linux<->Xen mapping which won't be the case and all hypercalls referring to these CPUs will end up affecting some other CPUs. -- Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
