From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753567AbdBGJa1 (ORCPT ); Tue, 7 Feb 2017 04:30:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16476 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752011AbdBGJ3G (ORCPT ); Tue, 7 Feb 2017 04:29:06 -0500 From: Vitaly Kuznetsov To: "Rafael J. Wysocki" Cc: "the arch\/x86 maintainers" , ACPI Devel Maling List , Linux Kernel Mailing List , "linux-ia64\@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Jones Subject: Re: [PATCH] x86/acpi: keep x86_cpu_to_acpiid mapping valid on cpu hotplug References: <20170206170151.25542-1-vkuznets@redhat.com> Date: Tue, 07 Feb 2017 10:29:03 +0100 In-Reply-To: (Rafael J. Wysocki's message of "Mon, 6 Feb 2017 22:05:57 +0100") Message-ID: <87shnqs61s.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 07 Feb 2017 09:29:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Rafael J. Wysocki" writes: > On Mon, Feb 6, 2017 at 6:01 PM, Vitaly Kuznetsov 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 >> Signed-off-by: Vitaly Kuznetsov > > 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