linux-kernel - Re: [patch 37/53] x86/cpu: Detect real BSP on crash kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y1czkdlg.ffs@tglx>
Date: Mon, 08 Jan 2024 17:13:31 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Zhang, Rui" <rui.zhang@...el.com>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Cc: "jgross@...e.com" <jgross@...e.com>, "arjan@...ux.intel.com"
 <arjan@...ux.intel.com>, "kprateek.nayak@....com"
 <kprateek.nayak@....com>, "x86@...nel.org" <x86@...nel.org>,
 "kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>,
 "thomas.lendacky@....com" <thomas.lendacky@....com>, "ray.huang@....com"
 <ray.huang@....com>, "andrew.cooper3@...rix.com"
 <andrew.cooper3@...rix.com>, "Sivanich, Dimitri"
 <dimitri.sivanich@....com>, "paulmck@...nel.org" <paulmck@...nel.org>,
 "Mehta, Sohil" <sohil.mehta@...el.com>, "andy@...radead.org"
 <andy@...radead.org>, "Tang, Feng" <feng.tang@...el.com>
Subject: Re: [patch 37/53] x86/cpu: Detect real BSP on crash kernels

On Mon, Jan 08 2024 at 15:54, Thomas Gleixner wrote:

> On Mon, Jan 08 2024 at 14:11, Zhang, Rui wrote:
>>> +static __init void check_for_kdump_kernel(void)
>>> +{
>>> +       u32 bsp_apicid;
>>> +
>>> +       /*
>>> +        * There is no real good way to detect whether this a kdump()
>>> +        * kernel, but except on the Voyager SMP monstrosity which is
>>> not
>>> +        * longer supported, the real BSP has always the lowest
>>> numbered
>>> +        * APIC ID. If a crash happened on an AP, which then ends up
>>> as
>>> +        * boot CPU in the kdump() kernel, then sending INIT to the
>>> real
>>> +        * BSP would reset the whole system.
>>> +        */
>>
>>
>> Hi, Thomas,
>>
>> Unfortunately this causes a regression on Intel Meteorlake platform,
>> where the BSP APIC ID is NOT the lowest numbered APIC ID (instead,
>> CPU12, the first Ecore CPU, has APIC ID 0).
>
> Bah. Let me think about that.

In which order are the APICs/CPUs enumerated by ACPI?