Received-SPF: pass (google.com: domain of linux-kernel+bounces-25813-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Thomas Gleixner <tglx@linutronix.de>
To: "Zhang, Rui" <rui.zhang@intel.com>, "Brown, Len" <len.brown@intel.com>,
 "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
In-Reply-To: <365568d9441d74516d0bfb802018ee0943b1b94b.camel@intel.com>
References: <20230807130108.853357011@linutronix.de>
 <20230807135028.381851690@linutronix.de>
 <7443f3200ef0be756566059e8c9b0657f3cefcff.camel@intel.com>
 <871qarlvub.ffs@tglx> <87y1czkdlg.ffs@tglx>
 <ff58623cdf63dc75fc245fd18ee776465f4bb3b8.camel@intel.com>
 <87frz5jmnl.ffs@tglx> <87a5pdjk54.ffs@tglx>
 <dbad0f6f9dee5851aa21ffae9e8877cf23645af5.camel@intel.com>
 <87edemimrj.ffs@tglx>
 <365568d9441d74516d0bfb802018ee0943b1b94b.camel@intel.com>
Date: Mon, 15 Jan 2024 10:41:49 +0100
Message-ID: <87a5p7gcgy.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On Sat, Jan 13 2024 at 07:35, Zhang, Rui wrote:
> On Fri, 2024-01-12 at 16:39 +0100, Thomas Gleixner wrote:
>> It brings the effect that we can detect when we are not booting
>> (kexec
>> case) on the actual boot CPU because then the first enumerated APIC
>> ID
>> is not the same as the boot CPU APIC ID. No?
>
> Right.
> I was thinking in the way this patch series does, which just compares
> the boot CPU APIC ID and the lowest numbered APIC ID.

Yes, that's obviously not working when the lowest APIC ID is not the
actual boot CPU.

>> I agree that MADT is error prone too given the fact that not even
>> Intel
>> can get it right....
>
> For this MTL, I can raise an internal ticket to get it right.
>
> Are there quite some platforms with BSP not listed as the first entry
> in MADT?
> if so, we still have to live with the kexec boot parameter? :)

I haven't found one yet, but you might look through the P/E systems to
get a picture.