Received: by 2002:a05:7412:40d:b0:e2:908c:2ebd with SMTP id 13csp1179057rdf; Wed, 22 Nov 2023 07:35:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IFkv9En6Lqa6iZ8JyWbZ1GaT9v4jj/sZtzKCKWWvQKzJCfpBHvEf5wPNv6CXWFaSmDulBS8 X-Received: by 2002:a05:6a20:7f95:b0:18a:e6aa:cd6a with SMTP id d21-20020a056a207f9500b0018ae6aacd6amr2959311pzj.30.1700667311372; Wed, 22 Nov 2023 07:35:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700667311; cv=none; d=google.com; s=arc-20160816; b=AXPUgQcfY0R0duOeTuUTIECZeQvcSMGqOOqibYQACLA9smn4EwBmwLu0lyS6J5vigO M0ISJ8XOt5ZAtT0+vm81HNDtnt4fX4Fl/VgmuM1tG0nmpFSspEajJenZD7GW5et7oKJW M0AxWE5rNjs0H7O1/pc2T3z0j2nzPLgwcngRmSw4aMwWT5tx6DQangewH3YOypWBIoAI YP9aHdFTjTQKjZnWq79eCG+bWAA67HWcvJUmJFYl0xojSQcUBwmG0e/xiSErvR5ztMBg CWg9V4BBLPI72L258Fy9ZvNjxaWiAGJhvalV1+VDPh5UWLUJMl8hNVX+upbt9K2pwvHU DjQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=177KqIy2AXV8uC74mfWkoziI8DNU60Xi+L8v0QSCveQ=; fh=4qZJs+1Th4Hm+yDQ6Sfef5taEHXNObyDs+Afk5fdyJs=; b=cZSDnTwJPh9qtOWqJ8bWc4OlIOUspCt0Zdb2lElRb5FOJICtXyp1MEY8b1ygHZ83wc llGOgm7K/nrRZIv/i6cjIcAz04/aZHHBIS7j2J/sQLfdnwhiFLzF+rTVs2bRrKHV6kw7 aiULeOTd3govuR54+OwR7CG0eqkiAFhIkpRlOBlrb5YCg1UK/Mgd8KB7PHiSrGQC9usW zI8CZCjiYTUkrmyt8CQVtuRYkuAvLh56QSuLYFq8w0VXcm2nX5r+chllKKYvrfPCsESk +tAERORUIDxer0W8GfNLfmx1Iu7ALDYO9ZWj2VqPohRqkjVq4hkIcBEA9IQMoxKMauHM Yrzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ELRGrr3c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id bx10-20020a056a02050a00b005b7ce261d0dsi14176424pgb.402.2023.11.22.07.35.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 07:35:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ELRGrr3c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 316B28212AA9; Wed, 22 Nov 2023 07:35:01 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344403AbjKVPex (ORCPT + 99 others); Wed, 22 Nov 2023 10:34:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235342AbjKVPeb (ORCPT ); Wed, 22 Nov 2023 10:34:31 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BDC5210E; Wed, 22 Nov 2023 07:33:49 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61620C43391; Wed, 22 Nov 2023 15:33:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700667228; bh=AeJqRHUr/7MlUMzFdObLGuXz7XEznAcDKOMUlbOqsBw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ELRGrr3cz3psjz4VoxttLn9j+BWBXu4qrEoI4yhFe/FD+VUMxwSOUBOnwMPCJyhLQ OyBMheV7J5Xqs4s4iSv21BIPN9NXOANxATqbBiu5kRaDl2UwmNEmlt5Tbzpo/Becg7 TT5obU7qwwSop9krONCnDJEeIgld+QcFTUlKDu7nQx38miHWRMDB9XSXEi5l0JU9uW m0nWzdC3A8Z4ZrLDVLGhrEzb8+9Ot6nfY2TieyJAE/fgP1eRbHUYIaGNGSPmvHYTZV Bh8T1od0iudmmg6fR7d2wvE3bDo2kpttOkgmytG2V8Ke1ZhfwXT9IcfAAHlswAU0Ye jnLp/GtZ3HbMg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhang Rui , Thomas Gleixner , Peter Zijlstra , Sasha Levin , 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.5 02/15] x86/acpi: Ignore invalid x2APIC entries Date: Wed, 22 Nov 2023 10:33:04 -0500 Message-ID: <20231122153340.852434-2-sashal@kernel.org> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231122153340.852434-1-sashal@kernel.org> References: <20231122153340.852434-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.5.12 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 22 Nov 2023 07:35:01 -0800 (PST) From: Zhang Rui [ 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 Signed-off-by: Thomas Gleixner Tested-by: Peter Zijlstra Link: https://lore.kernel.org/r/20230702162802.344176-1-rui.zhang@intel.com Signed-off-by: Sasha Levin --- 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 9cc9f12679f14..fb0c5f6afa197 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 @@ -236,6 +237,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 @@ -1118,10 +1127,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; @@ -1130,21 +1136,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