From: "Zhang, Rui" <rui.zhang@intel.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "jgross@suse.com" <jgross@suse.com>,
"x86@kernel.org" <x86@kernel.org>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"kprateek.nayak@amd.com" <kprateek.nayak@amd.com>,
"Tang, Feng" <feng.tang@intel.com>,
"kan.liang@linux.intel.com" <kan.liang@linux.intel.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"ray.huang@amd.com" <ray.huang@amd.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"Sivanich, Dimitri" <dimitri.sivanich@hpe.com>,
"paulmck@kernel.org" <paulmck@kernel.org>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
"andy@infradead.org" <andy@infradead.org>
Subject: Re: [patch 37/53] x86/cpu: Detect real BSP on crash kernels
Date: Tue, 9 Jan 2024 01:54:17 +0000 [thread overview]
Message-ID: <ff58623cdf63dc75fc245fd18ee776465f4bb3b8.camel@intel.com> (raw)
In-Reply-To: <87y1czkdlg.ffs@tglx>
On Mon, 2024-01-08 at 17:13 +0100, Thomas Gleixner wrote:
> 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?
This is the order in MADT,
$ cat apic.dsl | grep x2Apic
[030h 0048 4] Processor x2Apic ID : 00000010
[040h 0064 4] Processor x2Apic ID : 00000011
[050h 0080 4] Processor x2Apic ID : 00000018
[060h 0096 4] Processor x2Apic ID : 00000019
[070h 0112 4] Processor x2Apic ID : 00000020
[080h 0128 4] Processor x2Apic ID : 00000021
[090h 0144 4] Processor x2Apic ID : 00000028
[0A0h 0160 4] Processor x2Apic ID : 00000029
[0B0h 0176 4] Processor x2Apic ID : 00000030
[0C0h 0192 4] Processor x2Apic ID : 00000031
[0D0h 0208 4] Processor x2Apic ID : 00000038
[0E0h 0224 4] Processor x2Apic ID : 00000039
[0F0h 0240 4] Processor x2Apic ID : 00000000
[100h 0256 4] Processor x2Apic ID : 00000002
[110h 0272 4] Processor x2Apic ID : 00000004
[120h 0288 4] Processor x2Apic ID : 00000006
[130h 0304 4] Processor x2Apic ID : 00000008
[140h 0320 4] Processor x2Apic ID : 0000000A
[150h 0336 4] Processor x2Apic ID : 0000000C
[160h 0352 4] Processor x2Apic ID : 0000000E
[170h 0368 4] Processor x2Apic ID : 00000040
[180h 0384 4] Processor x2Apic ID : 00000042
and this is the order in Linux (from CPU0 to CPUN)
x2APIC ID of logical processor = 0x20 (32)
x2APIC ID of logical processor = 0x10 (16)
x2APIC ID of logical processor = 0x11 (17)
x2APIC ID of logical processor = 0x18 (24)
x2APIC ID of logical processor = 0x19 (25)
x2APIC ID of logical processor = 0x21 (33)
x2APIC ID of logical processor = 0x28 (40)
x2APIC ID of logical processor = 0x29 (41)
x2APIC ID of logical processor = 0x30 (48)
x2APIC ID of logical processor = 0x31 (49)
x2APIC ID of logical processor = 0x38 (56)
x2APIC ID of logical processor = 0x39 (57)
x2APIC ID of logical processor = 0x0 (0)
x2APIC ID of logical processor = 0x2 (2)
x2APIC ID of logical processor = 0x4 (4)
x2APIC ID of logical processor = 0x6 (6)
x2APIC ID of logical processor = 0x8 (8)
x2APIC ID of logical processor = 0xa (10)
x2APIC ID of logical processor = 0xc (12)
x2APIC ID of logical processor = 0xe (14)
x2APIC ID of logical processor = 0x40 (64)
x2APIC ID of logical processor = 0x42 (66)
thanks,
rui
next prev parent reply other threads:[~2024-01-09 1:54 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 13:52 [patch 00/53] x86/topology: The final installment Thomas Gleixner
2023-08-07 13:52 ` [patch 01/53] x86/cpu/topology: Cure off by one in fake_topology() Thomas Gleixner
2023-08-07 13:52 ` [patch 02/53] x86/cpu/topology: Make the APIC mismatch warnings complete Thomas Gleixner
2023-08-07 14:28 ` Arjan van de Ven
2023-08-07 14:54 ` Thomas Gleixner
2023-08-07 13:52 ` [patch 03/53] x86/platform/ce4100: Dont override x86_init.mpparse.setup_ioapic_ids Thomas Gleixner
2023-08-07 15:20 ` Andy Shevchenko
2023-08-07 13:52 ` [patch 04/53] x86/ioapic: Replace some more set bit nonsense Thomas Gleixner
2023-08-07 13:52 ` [patch 05/53] x86/apic: Get rid of get_physical_broadcast() Thomas Gleixner
2023-08-07 15:24 ` Andy Shevchenko
2023-08-07 13:52 ` [patch 06/53] x86/ioapic: Make io_apic_get_unique_id() simpler Thomas Gleixner
2023-08-07 13:52 ` [patch 07/53] x86/ioapic: Simplify setup_ioapic_ids_from_mpc_nocheck() Thomas Gleixner
2023-08-07 13:52 ` [patch 08/53] x86/apic: Remove check_apicid_used() and ioapic_phys_id_map() Thomas Gleixner
2023-08-07 13:52 ` [patch 09/53] x86/mpparse: Rename default_find_smp_config() Thomas Gleixner
2023-08-07 16:03 ` Andy Shevchenko
2023-08-07 17:21 ` Thomas Gleixner
2023-08-07 13:52 ` [patch 10/53] x86/mpparse: Provide separate early/late callbacks Thomas Gleixner
2023-08-07 13:52 ` [patch 11/53] x86/mpparse: Prepare for callback separation Thomas Gleixner
2023-08-07 13:52 ` [patch 12/53] x86/dtb: Rename x86_dtb_init() Thomas Gleixner
2023-08-07 13:52 ` [patch 13/53] x86/platform/ce4100: Prepare for separate mpparse callbacks Thomas Gleixner
2023-08-07 13:52 ` [patch 14/53] x86/platform/intel-mid: " Thomas Gleixner
2023-08-07 16:07 ` Andy Shevchenko
2023-08-07 13:52 ` [patch 15/53] x86/jailhouse: " Thomas Gleixner
2023-08-07 13:52 ` [patch 16/53] x86/xen/smp_pv: " Thomas Gleixner
2023-08-07 13:53 ` [patch 17/53] x86/mpparse: Switch to new init callbacks Thomas Gleixner
2023-08-07 13:53 ` [patch 18/53] x86/mm/numa: Move early mptable evaluation into common code Thomas Gleixner
2023-08-07 13:53 ` [patch 19/53] x86/mpparse: Remove the physid_t bitmap wrapper Thomas Gleixner
2023-08-08 11:37 ` Andy Shevchenko
2023-08-07 13:53 ` [patch 20/53] x86/apic: Remove the pointless writeback of boot_cpu_physical_apicid Thomas Gleixner
2023-08-07 13:53 ` [patch 21/53] x86/apic: Remove yet another dubious callback Thomas Gleixner
2023-08-07 13:53 ` [patch 22/53] x86/apic: Use a proper define for invalid ACPI CPU ID Thomas Gleixner
2023-08-07 13:53 ` [patch 23/53] x86/cpu/topology: Move registration out of APIC code Thomas Gleixner
2023-08-07 13:53 ` [patch 24/53] x86/cpu/topology: Provide separate APIC registration functions Thomas Gleixner
2023-08-11 12:32 ` Zhang, Rui
2023-08-07 13:53 ` [patch 25/53] x86/acpi: Use new " Thomas Gleixner
2023-08-07 15:27 ` Peter Zijlstra
2023-08-07 15:35 ` Andrew Cooper
2023-08-07 15:41 ` Thomas Gleixner
2023-08-07 13:53 ` [patch 26/53] x86/jailhouse: Use new APIC registration function Thomas Gleixner
2023-08-07 13:53 ` [patch 27/53] x86/of: Use new APIC registration functions Thomas Gleixner
2023-08-07 13:53 ` [patch 28/53] x86/mpparse: Use new APIC registration function Thomas Gleixner
2023-08-07 13:53 ` [patch 29/53] x86/acpi: Dont invoke topology_register_apic() for XEN PV Thomas Gleixner
2023-08-07 13:53 ` [patch 30/53] x86/xen/smp_pv: Register fake APICs Thomas Gleixner
2023-08-07 13:53 ` [patch 31/53] x86/cpu/topology: Confine topology information Thomas Gleixner
2023-08-07 13:53 ` [patch 32/53] x86/cpu/topology: Simplify APIC registration Thomas Gleixner
2023-08-07 13:53 ` [patch 33/53] x86/cpu/topology: Use a data structure for topology info Thomas Gleixner
2023-08-07 13:53 ` [patch 34/53] x86/smpboot: Make error message actually useful Thomas Gleixner
2023-08-07 13:53 ` [patch 35/53] x86/cpu/topology: Sanitize the APIC admission logic Thomas Gleixner
2023-08-07 13:53 ` [patch 36/53] x86/cpu/topology: Rework possible CPU management Thomas Gleixner
2023-08-14 8:29 ` Zhang, Rui
2023-08-07 13:53 ` [patch 37/53] x86/cpu: Detect real BSP on crash kernels Thomas Gleixner
2024-01-08 14:11 ` Zhang, Rui
2024-01-08 14:54 ` Thomas Gleixner
2024-01-08 16:13 ` Thomas Gleixner
2024-01-09 1:54 ` Zhang, Rui [this message]
2024-01-10 14:19 ` Thomas Gleixner
2024-01-10 15:14 ` Thomas Gleixner
2024-01-11 1:52 ` Zhang, Rui
2024-01-12 9:14 ` Zhang, Rui
2024-01-12 15:39 ` Thomas Gleixner
2024-01-13 7:35 ` Zhang, Rui
2024-01-15 9:41 ` Thomas Gleixner
2023-08-07 13:53 ` [patch 38/53] x86/topology: Add a mechanism to track topology via APIC IDs Thomas Gleixner
2023-08-07 13:53 ` [patch 39/53] x86/cpu/topology: Reject unknown APIC IDs on ACPI hotplug Thomas Gleixner
2023-08-07 13:53 ` [patch 40/53] x86/cpu/topology: Assign hotpluggable CPUIDs during init Thomas Gleixner
2023-08-07 13:53 ` [patch 41/53] x86/xen/smp_pv: Count number of vCPUs early Thomas Gleixner
2023-08-07 13:53 ` [patch 42/53] x86/cpu/topology: Let XEN/PV use topology from CPUID/MADT Thomas Gleixner
2023-08-07 13:53 ` [patch 43/53] x86/cpu/topology: Use topology bitmaps for sizing Thomas Gleixner
2023-08-07 13:53 ` [patch 44/53] x86/cpu/topology: Mop up primary thread mask handling Thomas Gleixner
2023-08-07 13:53 ` [patch 45/53] x86/cpu/topology: Simplify cpu_mark_primary_thread() Thomas Gleixner
2023-08-07 13:53 ` [patch 46/53] x86/cpu/topology: Provide logical pkg/die mapping Thomas Gleixner
2023-08-07 13:53 ` [patch 47/53] x86/cpu/topology: Use topology logical mapping mechanism Thomas Gleixner
2023-08-07 13:53 ` [patch 48/53] x86/cpu/topology: Retrieve cores per package from topology bitmaps Thomas Gleixner
2023-08-07 13:53 ` [patch 49/53] x86: Use topology functions instead of smp_num_siblings where applicable Thomas Gleixner
2023-08-07 13:53 ` [patch 50/53] x86/cpu/topology: Rename smp_num_siblings Thomas Gleixner
2023-08-07 13:53 ` [patch 51/53] x86/cpu/topology: Rename topology_max_die_per_package() Thomas Gleixner
2023-08-07 13:53 ` [patch 52/53] x86/cpu/topology: Provide __num_[cores|threads]_per_package Thomas Gleixner
2023-08-07 13:53 ` [patch 53/53] x86/cpu/topology: Get rid of cpuinfo::x86_max_cores Thomas Gleixner
2023-08-11 15:44 ` Zhang, Rui
2023-12-14 14:00 ` Zhang, Rui
2023-08-08 7:40 ` [patch 00/53] x86/topology: The final installment Juergen Gross
2023-08-08 11:20 ` Andrew Cooper
2023-08-08 18:55 ` Thomas Gleixner
2023-08-08 18:29 ` Sohil Mehta
2023-08-08 19:10 ` Thomas Gleixner
2023-08-08 20:30 ` Sohil Mehta
2023-08-08 20:41 ` Thomas Gleixner
2023-08-08 22:10 ` Peter Zijlstra
2023-08-08 22:58 ` Sohil Mehta
2023-08-08 23:20 ` Thomas Gleixner
2023-08-09 16:55 ` Sohil Mehta
2023-08-10 3:28 ` Zhang, Rui
2023-08-09 16:50 ` Qiuxu Zhuo
2023-08-09 17:23 ` Sohil Mehta
2023-08-10 1:33 ` Zhuo, Qiuxu
2023-08-08 20:57 ` Thomas Gleixner
2023-08-09 16:12 ` Qiuxu Zhuo
2023-08-12 13:51 ` Michael Kelley (LINUX)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff58623cdf63dc75fc245fd18ee776465f4bb3b8.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=andy@infradead.org \
--cc=arjan@linux.intel.com \
--cc=dimitri.sivanich@hpe.com \
--cc=feng.tang@intel.com \
--cc=jgross@suse.com \
--cc=kan.liang@linux.intel.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=ray.huang@amd.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox