All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Chris Lindee <chris.lindee@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>,
	regressions@lists.linux.dev, Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ashok Raj <ashok.raj@intel.com>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: [PATCH] x86/smpboot/64: Handle X2APIC BIOS inconsistency gracefully
Date: Fri, 15 Dec 2023 09:58:58 +0100	[thread overview]
Message-ID: <87cyv7on8t.ffs@tglx> (raw)
In-Reply-To: <CA+2tU596G+auWJ2MzYFJ3bv=Y4zP2NSrdtak7SdF9SH6Ht_dzg@mail.gmail.com>

Chris reported that a Dell PowerEdge T340 system stopped to boot when
upgrading to a kernel which contains the parallel hotplug changes.
Disabling parallel hotplug on the kernel command line makes it boot again.

It turns out that the Dell BIOS has x2APIC enabled and the boot CPU comes
up in X2APIC mode, but the APs come up inconsistently in xAPIC mode.

Parallel hotplug requires that the upcoming CPU reads out its APIC ID from
the local APIC in order to map it to the Linux CPU number.

In this particular case the readout on the APs uses the MMIO mapped
registers because the BIOS failed to enable x2APIC mode. That readout
results in a pagefault because the kernel does not have the APIC MMIO space
mapped when X2APIC mode was enabled by the BIOS on the boot CPU and the
kernel switched to X2APIC mode early. That page fault can't be handled on
the upcoming CPU that early and results in a silent boot failure.

If parallel hotplug is disabled the system boots because in that case
the APIC ID read is not required as the Linux CPU number is provided to
the AP in the smpboot control word. When the kernel uses x2APIC mode
then the APs are switched to x2APIC mode too slightly later in the
bringup process, but there is no reason to do it that late.

Cure the BIOS bogosity by checking in the parallel bootup path whether the
kernel uses x2APIC mode and if so switching over the APs to x2APIC mode
before the APIC ID readout.

Fixes: 0c7ffa32dbd6 "x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it"
Reported-by: Chris Lindee <chris.lindee@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Chris Lindee <chris.lindee@gmail.com>
Cc: stable@vger.kernel.org
---
 arch/x86/kernel/head_64.S |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -268,6 +268,22 @@ SYM_INNER_LABEL(secondary_startup_64_no_
 	testl	$X2APIC_ENABLE, %eax
 	jnz	.Lread_apicid_msr
 
+#ifdef CONFIG_X86_X2APIC
+	/*
+	 * If system is in X2APIC mode then MMIO base mignt not be
+	 * mapped causing the MMIO read below to fault. Faults can't
+	 * be handled at that point.
+	 */
+	cmpl	$0, x2apic_mode(%rip)
+	jz	.Lread_apicid_mmio
+
+	/* Force the AP into X2APIC mode. */
+	orl	$X2APIC_ENABLE, %eax
+	wrmsr
+	jmp	.Lread_apicid_msr
+#endif
+
+.Lread_apicid_mmio:
 	/* Read the APIC ID from the fix-mapped MMIO space. */
 	movq	apic_mmio_base(%rip), %rcx
 	addq	$APIC_ID, %rcx

  parent reply	other threads:[~2023-12-15  8:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+2tU59853R49EaU_tyvOZuOTDdcU0RshGyydccp9R1NX9bEeQ@mail.gmail.com>
2023-12-10 11:05 ` [REGRESSION] x86/smpboot/64: System will not boot on v6.5, v6.7-rc4 Borislav Petkov
     [not found]   ` <CA+2tU585yW2z37NtYqjVe+ZMw+oU_vbS4X=Q=sAxME8GrPFDpg@mail.gmail.com>
2023-12-12 14:34     ` Thomas Gleixner
     [not found]       ` <CA+2tU5_TzDQO2U8SGDYhsVPR8iYh8Q8vTqv9+HUc7LN3cV=2Sg@mail.gmail.com>
2023-12-13 14:34         ` Thomas Gleixner
2023-12-13 21:08           ` Thomas Gleixner
     [not found]           ` <CA+2tU5-RoR8qCGRdsMH0wo5n8v4fV8A_H5yT+mZadsF7E+QkWg@mail.gmail.com>
     [not found]             ` <CA+2tU5-18YQSpFzgUKyeZdJXe0Rs0GxtYY2s5QjznzTucJKCiQ@mail.gmail.com>
2023-12-14  7:04               ` Thomas Gleixner
     [not found]                 ` <CA+2tU596G+auWJ2MzYFJ3bv=Y4zP2NSrdtak7SdF9SH6Ht_dzg@mail.gmail.com>
2023-12-15  8:58                   ` Thomas Gleixner [this message]
2023-12-15 15:41                     ` [PATCH] x86/smpboot/64: Handle X2APIC BIOS inconsistency gracefully Ashok Raj
     [not found]                       ` <CA+2tU5_hD-atkp9UcCJnL6TMneSOBxL87=ppvrQ1ugUn_0-7NA@mail.gmail.com>
2023-12-15 18:35                         ` Borislav Petkov
2023-12-12 15:32   ` [REGRESSION] x86/smpboot/64: System will not boot on v6.5, v6.7-rc4 Linux regression tracking #adding (Thorsten Leemhuis)
2024-03-11 19:47   ` Guenter Roeck
2024-03-12  9:13     ` Thorsten Leemhuis

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=87cyv7on8t.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=chris.lindee@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=regressions@lists.linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.