Message ID | 20230724132045.555787669@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9010:0:b0:3e4:2afc:c1 with SMTP id l16csp1835607vqg; Mon, 24 Jul 2023 07:25:19 -0700 (PDT) X-Google-Smtp-Source: APBJJlHb+ehlA4sFgrXI5/M7sCr7kf1HglhN/w/dJNfSkRmZaD1VM23R9vlEX6QETmbWbvd+7ah9 X-Received: by 2002:a05:6402:2039:b0:522:1e24:afb6 with SMTP id ay25-20020a056402203900b005221e24afb6mr5638179edb.0.1690208718790; Mon, 24 Jul 2023 07:25:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690208718; cv=none; d=google.com; s=arc-20160816; b=doHuv3yN4MAUyFR+PhIgO+MLTSTv6bgTZ6NJDWU2dw6guLXcfcLb5WRlfsYnotrDEP rwIhB+EC8H37b6kgsmeDVHWpSXRWkIT5Z0CJV1UCONl4LOzk7zDD5+WxCCj0L/r8cI4f c7RK11PVT75XinjYxsDzrOrsmTlEbbMDir7sWI2BLeROWe3niPJUB4RAWPggdrp651Yh tIq9WpeiHlPg+aNvmslHKTdQF3UMyhZLCchA/C3C5MGzHSupM+EvcJwod6y7CxjwI2Jl asRaCOWDU80jSjvP29TteRsBBhlWfYZI0yriR2AlV+zsY9Rox74gU7hONLA56P/UvQp1 E+0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:mime-version:references:subject:cc:to:from :dkim-signature:dkim-signature:message-id; bh=c71eHbYg+VP7OJhjZCVHVzp0AtRxO5V4C+TDLxCJHes=; fh=mE3iieUIZLcDfOLIULj9X6/p0bMDPZGFSVRsnyRUnTc=; b=l66/kgEApKDNc3rejUEapoHsE3SJjRM4TQckmYf7DPPtUQ4SS6RJDSuXHbTLcCbz21 Rc0Sj1XCvy1YjX/HdA1aIxIyiMwJiJZi2l0cZP0DqPLqp7EEtAcrfVrazuVRxqgrlrZ3 HSm7VJpiVa8pbDFFN0GR/eBfIVpeoJKoaGgkGrP3Tjo4Upz8BKBL3Gv2h668briSvPjk 1tkEZ1ZlrhJ+WF5JDMswR6b5vTcKD6RS6fapvdgQrXyMA0p5uJa1kLQ2kXWX8IWxyyej J51Aqc8Nja9xTqWgY3PSa7dqcSLZaSO2os/AsNeK2G94/r8+s+bhfSl0Ijpmhcwxstu8 Ftpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="Zdsd/qAk"; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y8-20020aa7d508000000b005221f9a302csi3001102edq.678.2023.07.24.07.24.54; Mon, 24 Jul 2023 07:25:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="Zdsd/qAk"; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231502AbjGXNfJ (ORCPT <rfc822;kautuk.consul.80@gmail.com> + 99 others); Mon, 24 Jul 2023 09:35:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231558AbjGXNeo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Jul 2023 09:34:44 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B5821FFE for <linux-kernel@vger.kernel.org>; Mon, 24 Jul 2023 06:34:18 -0700 (PDT) Message-ID: <20230724132045.555787669@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1690205652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=c71eHbYg+VP7OJhjZCVHVzp0AtRxO5V4C+TDLxCJHes=; b=Zdsd/qAkSfkyv7R28hxTmnj8gmeJl+Sk5X2N8xiveIMJFkd8XPmRlQrXnd/6VX5U+F2lIF kNXiNRZdmjiuN3l4BMGRZifB9vSb3+pwS/9cMLK1WALqkQa1l8cTRQQ0FmQQ/XXnhnaeod Y3ImaBtA0xH3dmU7EECqoF+Us6O2qG2htggxB3Y6+CHulp/UcO7ton+jsg09i0B3d2Cuxb XiL49T9wHAWaofWRJs5bEJHbPgev7b90L66QjmYnGAQNmuYIkQz3essgRe6hO9mPOgJan3 KWrDU9HCFkFxZghZOCw4JFX8yNzFja2B7eDgJc4F8mD8LsI17fnZbkWD+4F07w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1690205652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=c71eHbYg+VP7OJhjZCVHVzp0AtRxO5V4C+TDLxCJHes=; b=ZeJdIWWQ5lDzV+3Aicl/OcNNEhnGtBOTGMXALhCu54bgHHASFrWxy2Obb3Ogq3bHihKxoB pJbSvCno/WGeh7CA== From: Thomas Gleixner <tglx@linutronix.de> To: LKML <linux-kernel@vger.kernel.org> Cc: x86@kernel.org, Andrew Cooper <andrew.cooper3@citrix.com>, Tom Lendacky <thomas.lendacky@amd.com>, Paolo Bonzini <pbonzini@redhat.com>, Wei Liu <wei.liu@kernel.org>, Arjan van de Ven <arjan@linux.intel.com>, Juergen Gross <jgross@suse.com>, Michael Kelley <mikelley@microsoft.com>, Peter Keresztes Schmidt <peter@keresztesschmidt.de>, "Peter Zijlstra (Intel)" <peterz@infradead.org> Subject: [patch V2 16/58] x86/apic: Sanitize num_processors handling References: <20230724131206.500814398@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Date: Mon, 24 Jul 2023 15:34:11 +0200 (CEST) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772312297432407223 X-GMAIL-MSGID: 1772312297432407223 |
Series |
x86/apic: Decrapification and static calls
|
|
Commit Message
Thomas Gleixner
July 24, 2023, 1:34 p.m. UTC
num_processors is 0 by default and only gets incremented when local APICs are registered. Make init_apic_mappings(), which tries to enable the local APIC in the case that no SMP configuration was found set num_processors to 1. This allows to remove yet another check for the local APIC and yet another place which registers the boot CPUs local APIC ID. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- arch/x86/kernel/apic/apic.c | 9 ++++++--- arch/x86/kernel/smpboot.c | 18 ------------------ 2 files changed, 6 insertions(+), 21 deletions(-)
Comments
On 24.07.23 15:34, Thomas Gleixner wrote: > num_processors is 0 by default and only gets incremented when local APICs > are registered. > > Make init_apic_mappings(), which tries to enable the local APIC in the case > that no SMP configuration was found set num_processors to 1. > > This allows to remove yet another check for the local APIC and yet another > place which registers the boot CPUs local APIC ID. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> > --- > arch/x86/kernel/apic/apic.c | 9 ++++++--- > arch/x86/kernel/smpboot.c | 18 ------------------ > 2 files changed, 6 insertions(+), 21 deletions(-) > > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -2130,9 +2130,12 @@ void __init init_apic_mappings(void) > if (x2apic_mode) > return; > > - if (!smp_found_config && !detect_init_APIC()) { > - pr_info("APIC: disable apic facility\n"); > - apic_disable(); > + if (!smp_found_config) { > + if (!detect_init_APIC()) { > + pr_info("APIC: disable apic facility\n"); > + apic_disable(); > + } > + num_processors = 1; > } > } > This is introducing a regression for Xen PV guests: those have no ACPI tables, so smp_found_config will be 0. OTOH num_processors has been set already using hypervisor data, so setting num_processors to 1 here will overwrite the previous setting. Below diff on top is fixing the problem: diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 564d584c8b99..59c12b20c635 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -2135,7 +2135,13 @@ void __init init_apic_mappings(void) pr_info("APIC: disable apic facility\n"); apic_disable(); } - num_processors = 1; + + /* + * Unprivileged Xen PV guests have smp_found_config = 0, but + * they have set num_processors already from hypervisor data. + */ + if (!num_processors) + num_processors = 1; } } Juergen
On Mon, Jul 31 2023 at 12:17, Juergen Gross wrote: > On 24.07.23 15:34, Thomas Gleixner wrote: > This is introducing a regression for Xen PV guests: those have no ACPI > tables, so smp_found_config will be 0. OTOH num_processors has been set > already using hypervisor data, so setting num_processors to 1 here will > overwrite the previous setting. > > Below diff on top is fixing the problem: Fixing? You can't be serious about that. Why can't XENPV pretend that it has a smp configuration detected, i.e. setting smp_found_config as any other special get_smp_config() implementation does? XENPV is already a major pain to deal with. No need to expand the related insanity all over the place. Thanks, tglx
On Mon, Jul 31 2023 at 14:50, Thomas Gleixner wrote: > Why can't XENPV pretend that it has a smp configuration detected, > i.e. setting smp_found_config as any other special get_smp_config() > implementation does? The below should do the trick, no? --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -182,7 +182,8 @@ static void __init _get_smp_config(unsig if (subtract) set_nr_cpu_ids(nr_cpu_ids - subtract); #endif - + /* Pretend to be a proper enumerated system */ + smp_found_config = 1; } static void __init xen_pv_smp_prepare_boot_cpu(void)
On 31.07.23 17:57, Thomas Gleixner wrote: > On Mon, Jul 31 2023 at 14:50, Thomas Gleixner wrote: >> Why can't XENPV pretend that it has a smp configuration detected, >> i.e. setting smp_found_config as any other special get_smp_config() >> implementation does? > > The below should do the trick, no? Something like that, yes. I'm just hunting another regression in the series. With patch 23 of the topology series applied the APs of a Xen PV guests won't be onlined. I guess this is due to missing topology data initialization somewhere in the Xen related code. I'll check your suggestion after finding the reason for the regression. Juergen > > > --- a/arch/x86/xen/smp_pv.c > +++ b/arch/x86/xen/smp_pv.c > @@ -182,7 +182,8 @@ static void __init _get_smp_config(unsig > if (subtract) > set_nr_cpu_ids(nr_cpu_ids - subtract); > #endif > - > + /* Pretend to be a proper enumerated system */ > + smp_found_config = 1; > } > > static void __init xen_pv_smp_prepare_boot_cpu(void)
On 31.07.23 20:19, Juergen Gross wrote: > On 31.07.23 17:57, Thomas Gleixner wrote: >> On Mon, Jul 31 2023 at 14:50, Thomas Gleixner wrote: >>> Why can't XENPV pretend that it has a smp configuration detected, >>> i.e. setting smp_found_config as any other special get_smp_config() >>> implementation does? >> >> The below should do the trick, no? > > Something like that, yes. > > I'm just hunting another regression in the series. With patch 23 of the > topology series applied the APs of a Xen PV guests won't be onlined. I > guess this is due to missing topology data initialization somewhere in > the Xen related code. > > I'll check your suggestion after finding the reason for the regression. > >> >> >> --- a/arch/x86/xen/smp_pv.c >> +++ b/arch/x86/xen/smp_pv.c >> @@ -182,7 +182,8 @@ static void __init _get_smp_config(unsig >> if (subtract) >> set_nr_cpu_ids(nr_cpu_ids - subtract); >> #endif >> - >> + /* Pretend to be a proper enumerated system */ >> + smp_found_config = 1; >> } >> static void __init xen_pv_smp_prepare_boot_cpu(void) > It is working fine. Juergen
--- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -2130,9 +2130,12 @@ void __init init_apic_mappings(void) if (x2apic_mode) return; - if (!smp_found_config && !detect_init_APIC()) { - pr_info("APIC: disable apic facility\n"); - apic_disable(); + if (!smp_found_config) { + if (!detect_init_APIC()) { + pr_info("APIC: disable apic facility\n"); + apic_disable(); + } + num_processors = 1; } } --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -1397,24 +1397,6 @@ early_param("possible_cpus", _setup_poss { int i, possible; - /* No processor was found in mptable or ACPI MADT */ - if (!num_processors) { - if (boot_cpu_has(X86_FEATURE_APIC)) { - int apicid = boot_cpu_physical_apicid; - int cpu = read_apic_id(); - - pr_warn("Boot CPU (id %d) not listed by BIOS\n", cpu); - - /* Make sure boot cpu is enumerated */ - if (apic->cpu_present_to_apicid(0) == BAD_APICID && - apic->apic_id_valid(apicid)) - generic_processor_info(apicid); - } - - if (!num_processors) - num_processors = 1; - } - i = setup_max_cpus ?: 1; if (setup_possible_cpus == -1) { possible = num_processors;