Received-SPF: pass (google.com: domain of linux-kernel+bounces-24815-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
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: <dbad0f6f9dee5851aa21ffae9e8877cf23645af5.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>
Date: Fri, 12 Jan 2024 16:39:44 +0100
Message-ID: <87edemimrj.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 12 2024 at 09:14, Zhang, Rui wrote:
> On Wed, 2024-01-10 at 16:14 +0100, Thomas Gleixner wrote:
>> On Wed, Jan 10 2024 at 15:19, Thomas Gleixner wrote:
>> > > This is the order in MADT,
>> > > $ cat apic.dsl=C2=A0 | grep x2Apic
>> > > [030h 0048=C2=A0=C2=A0 4]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Processor x2Apic ID : 00000010
>> > > [040h 0064=C2=A0=C2=A0 4]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Processor x2Apic ID : 00000011
>> ...
>> > > and this is the order in Linux (from CPU0 to CPUN)
>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x2APIC ID of logical processor =3D 0x=
20 (32)
>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x2APIC ID of logical processor =3D 0x=
10 (16)
>> >=20
>> > What a mess...
>>=20
>> And clearly not according to the spec
>>=20
>> =C2=A0 "The second is that platform firmware should list the boot
>> processor
>> =C2=A0=C2=A0 as the first processor entry in the MADT."
>>=20
>> Oh well. There are reasons why this is written the way it is.
>
> This is indeed a violation of the ACPI spec and we should modify the
> order in MADT. But this doesn't bring any actual effect as Linux
> already handles this, right?

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?

> For the BSP APIC ID 0x20, I didn't find out a specific reason why we
> have to do it in that way, but it is still legal.

Linux does not really care in which order the APICs are enumerated.

> We may need to figure out another way to distinguish the kdump kernel.

Having the first enumerated APIC in the MADT as the actual boot CPU is a
sensible and functional way. Everything else including the silly kexec
boot parameter is error prone.

I agree that MADT is error prone too given the fact that not even Intel
can get it right....

Thanks,

        tglx