All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Zhang Rui <rui.zhang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Sasha Levin <sashal@kernel.org>,
	rafael@kernel.org, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org,
	linux-acpi@vger.kernel.org
Subject: [PATCH AUTOSEL 6.6 02/17] x86/acpi: Ignore invalid x2APIC entries
Date: Wed, 22 Nov 2023 10:31:31 -0500	[thread overview]
Message-ID: <20231122153212.852040-2-sashal@kernel.org> (raw)
In-Reply-To: <20231122153212.852040-1-sashal@kernel.org>

From: Zhang Rui <rui.zhang@intel.com>

[ Upstream commit ec9aedb2aa1ab7ac420c00b31f5edc5be15ec167 ]

Currently, the kernel enumerates the possible CPUs by parsing both ACPI
MADT Local APIC entries and x2APIC entries. So CPUs with "valid" APIC IDs,
even if they have duplicated APIC IDs in Local APIC and x2APIC, are always
enumerated.

Below is what ACPI MADT Local APIC and x2APIC describes on an
Ivebridge-EP system,

[02Ch 0044   1]                Subtable Type : 00 [Processor Local APIC]
[02Fh 0047   1]                Local Apic ID : 00
...
[164h 0356   1]                Subtable Type : 00 [Processor Local APIC]
[167h 0359   1]                Local Apic ID : 39
[16Ch 0364   1]                Subtable Type : 00 [Processor Local APIC]
[16Fh 0367   1]                Local Apic ID : FF
...
[3ECh 1004   1]                Subtable Type : 09 [Processor Local x2APIC]
[3F0h 1008   4]                Processor x2Apic ID : 00000000
...
[B5Ch 2908   1]                Subtable Type : 09 [Processor Local x2APIC]
[B60h 2912   4]                Processor x2Apic ID : 00000077

As a result, kernel shows "smpboot: Allowing 168 CPUs, 120 hotplug CPUs".
And this wastes significant amount of memory for the per-cpu data.
Plus this also breaks https://lore.kernel.org/all/87edm36qqb.ffs@tglx/,
because __max_logical_packages is over-estimated by the APIC IDs in
the x2APIC entries.

According to https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-local-x2apic-structure:

  "[Compatibility note] On some legacy OSes, Logical processors with APIC
   ID values less than 255 (whether in XAPIC or X2APIC mode) must use the
   Processor Local APIC structure to convey their APIC information to OSPM,
   and those processors must be declared in the DSDT using the Processor()
   keyword. Logical processors with APIC ID values 255 and greater must use
   the Processor Local x2APIC structure and be declared using the Device()
   keyword."

Therefore prevent the registration of x2APIC entries with an APIC ID less
than 255 if the local APIC table enumerates valid APIC IDs.

[ tglx: Simplify the logic ]

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20230702162802.344176-1-rui.zhang@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/kernel/acpi/boot.c | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index c55c0ef47a187..fc5bce1b50476 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -63,6 +63,7 @@ int acpi_fix_pin2_polarity __initdata;
 
 #ifdef CONFIG_X86_LOCAL_APIC
 static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
+static bool has_lapic_cpus __initdata;
 static bool acpi_support_online_capable;
 #endif
 
@@ -232,6 +233,14 @@ acpi_parse_x2apic(union acpi_subtable_headers *header, const unsigned long end)
 	if (!acpi_is_processor_usable(processor->lapic_flags))
 		return 0;
 
+	/*
+	 * According to https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#processor-local-x2apic-structure
+	 * when MADT provides both valid LAPIC and x2APIC entries, the APIC ID
+	 * in x2APIC must be equal or greater than 0xff.
+	 */
+	if (has_lapic_cpus && apic_id < 0xff)
+		return 0;
+
 	/*
 	 * We need to register disabled CPU as well to permit
 	 * counting disabled CPUs. This allows us to size
@@ -1114,10 +1123,7 @@ static int __init early_acpi_parse_madt_lapic_addr_ovr(void)
 
 static int __init acpi_parse_madt_lapic_entries(void)
 {
-	int count;
-	int x2count = 0;
-	int ret;
-	struct acpi_subtable_proc madt_proc[2];
+	int count, x2count = 0;
 
 	if (!boot_cpu_has(X86_FEATURE_APIC))
 		return -ENODEV;
@@ -1126,21 +1132,11 @@ static int __init acpi_parse_madt_lapic_entries(void)
 				      acpi_parse_sapic, MAX_LOCAL_APIC);
 
 	if (!count) {
-		memset(madt_proc, 0, sizeof(madt_proc));
-		madt_proc[0].id = ACPI_MADT_TYPE_LOCAL_APIC;
-		madt_proc[0].handler = acpi_parse_lapic;
-		madt_proc[1].id = ACPI_MADT_TYPE_LOCAL_X2APIC;
-		madt_proc[1].handler = acpi_parse_x2apic;
-		ret = acpi_table_parse_entries_array(ACPI_SIG_MADT,
-				sizeof(struct acpi_table_madt),
-				madt_proc, ARRAY_SIZE(madt_proc), MAX_LOCAL_APIC);
-		if (ret < 0) {
-			pr_err("Error parsing LAPIC/X2APIC entries\n");
-			return ret;
-		}
-
-		count = madt_proc[0].count;
-		x2count = madt_proc[1].count;
+		count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
+					acpi_parse_lapic, MAX_LOCAL_APIC);
+		has_lapic_cpus = count > 0;
+		x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
+					acpi_parse_x2apic, MAX_LOCAL_APIC);
 	}
 	if (!count && !x2count) {
 		pr_err("No LAPIC entries present\n");
-- 
2.42.0


  reply	other threads:[~2023-11-22 15:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 15:31 [PATCH AUTOSEL 6.6 01/17] scsi: sd: Fix sshdr use in sd_suspend_common() Sasha Levin
2023-11-22 15:31 ` Sasha Levin [this message]
2023-12-06  7:04   ` [PATCH AUTOSEL 6.6 02/17] x86/acpi: Ignore invalid x2APIC entries Andres Freund
2023-12-12 16:17     ` Thomas Gleixner
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 03/17] hrtimers: Push pending hrtimers away from outgoing CPU earlier Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 04/17] i2c: designware: Fix corrupted memory seen in the ISR Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 05/17] i2c: ocores: Move system PM hooks to the NOIRQ phase Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 06/17] netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 07/17] nouveau: use an rwlock for the event lock Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31   ` [Nouveau] " Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 08/17] zstd: Fix array-index-out-of-bounds UBSAN warning Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 09/17] tg3: Move the [rt]x_dropped counters to tg3_napi Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 10/17] tg3: Increment tx_dropped in tg3_tso_bug() Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 11/17] modpost: fix section mismatch message for RELA Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 12/17] linux/export: clean up the IA-64 KSYM_FUNC macro Sasha Levin
2023-11-22 20:06   ` Lukas Bulwahn
2023-12-06  1:57     ` Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 13/17] kconfig: fix memory leak from range properties Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 14/17] drm/amdgpu: Do not program VF copy regs in mmhub v1.8 under SRIOV (v2) Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 15/17] drm/amdgpu: finalizing mem_partitions at the end of GMC v9 sw_fini Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 16/17] drm/amdgpu: correct chunk_ptr to a pointer to chunk Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31   ` Sasha Levin
2023-11-22 15:31 ` [PATCH AUTOSEL 6.6 17/17] dm-crypt: start allocating with MAX_ORDER Sasha Levin

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=20231122153212.852040-2-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --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.