summaryrefslogtreecommitdiff
path: root/arch/x86/pci/mmconfig-shared.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2024-05-17 17:40:36 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-06-12 12:39:57 +0300
commit268ea2acacf01c1be3f0ba002df8b216d7b7d8ae (patch)
tree0ce628a8a5abd90af22f617b9d8fcfa6f362f746 /arch/x86/pci/mmconfig-shared.c
parent6ca67a5fe1c606d1fbe24c30a9fc0bdc43a18554 (diff)
downloadlinux-268ea2acacf01c1be3f0ba002df8b216d7b7d8ae.tar.xz
x86/topology: Handle bogus ACPI tables correctly
commit 9d22c96316ac59ed38e80920c698fed38717b91b upstream. The ACPI specification clearly states how the processors should be enumerated in the MADT: "To ensure that the boot processor is supported post initialization, two guidelines should be followed. The first is that OSPM should initialize processors in the order that they appear in the MADT. The second is that platform firmware should list the boot processor as the first processor entry in the MADT. ... Failure of OSPM implementations and platform firmware to abide by these guidelines can result in both unpredictable and non optimal platform operation." The kernel relies on that ordering to detect the real BSP on crash kernels which is important to avoid sending a INIT IPI to it as that would cause a full machine reset. On a Dell XPS 16 9640 the BIOS ignores this rule and enumerates the CPUs in the wrong order. As a consequence the kernel falsely detects a crash kernel and disables the corresponding CPU. Prevent this by checking the IA32_APICBASE MSR for the BSP bit on the boot CPU. If that bit is set, then the MADT based BSP detection can be safely ignored. If the kernel detects a mismatch between the BSP bit and the first enumerated MADT entry then emit a firmware bug message. This obviously also has to be taken into account when the boot APIC ID and the first enumerated APIC ID match. If the boot CPU does not have the BSP bit set in the APICBASE MSR then there is no way for the boot CPU to determine which of the CPUs is the real BSP. Sending an INIT to the real BSP would reset the machine so the only sane way to deal with that is to limit the number of CPUs to one and emit a corresponding warning message. Fixes: 5c5682b9f87a ("x86/cpu: Detect real BSP on crash kernels") Reported-by: Carsten Tolkmit <ctolkmit@ennit.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Carsten Tolkmit <ctolkmit@ennit.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87le48jycb.ffs@tglx Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218837 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/x86/pci/mmconfig-shared.c')
0 files changed, 0 insertions, 0 deletions