Message ID | 20230419155341.v8.7.I21d92f8974c8e4001a5982fea6c98da1bed33ef5@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp715577vqo; Wed, 19 Apr 2023 15:58:58 -0700 (PDT) X-Google-Smtp-Source: AKy350YzQkIHQFQBge94L09zaVDtpOPwE+tU4saz6dEHbbCA+7fFVTb+Fv/iYHdR2Q2tvRLCmmGf X-Received: by 2002:a05:6a21:788d:b0:f0:9e73:c77b with SMTP id bf13-20020a056a21788d00b000f09e73c77bmr216557pzc.20.1681945138637; Wed, 19 Apr 2023 15:58:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681945138; cv=none; d=google.com; s=arc-20160816; b=QXPJJmlXOm11iKcklxzO+U/+lCNKuo7YdnvF7hSmpbErhF035PKTdaeD7dIWAsWfmq +0HLrFXon2ta17/pNCpY0fPFpMuIRncZt72oVuX5Ss7WpASSToHqbJZAc+79N+o8b89p 6RWM7hHCsHHjdCwGwXSObUUtqCybe+wB7FrBcSv4HEdMe5B+KYmDzCIQdmHik+i9xcmC DZl+u2oSKLmf4X+MNiZL2oiEii2Ez+u7ofZgnQwedZNHe2Gyu/w64NKFlfnU3Zq0+lKb FLKqMV+ZY/PUUpPeR9wZftqCiYAyfsCk9D/6W9I14P+YvLKwptKs02BMWZ7eMWAFppKa KOFg== 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=g22FS7H3jiae+Nq35iKba9yRyiXUFZk5tjGcb2Ngrro=; b=ZLdply2eRAO6aVEAvOw2HfLNUP18IyjpLfanjRJfH8gjAQa5LxQBgzmooqdqZlH1LV APYAhZ/F6AxjzW8ARo5/Yk3SG2QlsKStcnTxhrP1opDsVqb7WIDaFw1X02om/hje0oXo /S/FF9xDHa0S0Jig9zS3fsHMRQKmO7Me94LRSGA8BWPUk328OtZzh75n6/sccoNdqFcN dq59iOwRo5dqQaL8FV5O0r0MYnld5M9D4TgB1Zhva/oYhhMYJL2uK+QrRwQ6f2Rllmkn 0tz7Sh22L+zPCwU36mn0o3GFuJ79EcIYAcAts+az7Me9WTQhzulcxn/PY7wuP/M0Aou7 sh0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=I12V15zv; 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=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a26-20020aa795ba000000b0063732344e2fsi10333968pfk.190.2023.04.19.15.58.42; Wed, 19 Apr 2023 15:58:58 -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=@chromium.org header.s=google header.b=I12V15zv; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233786AbjDSW5o (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Wed, 19 Apr 2023 18:57:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233728AbjDSW5Y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Apr 2023 18:57:24 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48D8C5BBF for <linux-kernel@vger.kernel.org>; Wed, 19 Apr 2023 15:57:18 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-51f597c97c5so255686a12.0 for <linux-kernel@vger.kernel.org>; Wed, 19 Apr 2023 15:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1681945037; x=1684537037; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=g22FS7H3jiae+Nq35iKba9yRyiXUFZk5tjGcb2Ngrro=; b=I12V15zv0C6apw691aW9levIxgdcSXiKj994KdL77DgbZjGB9+wGZjupAC8Yjj+94l I2rEcmLlXEU/axqyDoo0R6CwAxucD+HcDQl0ePN+qZMHOnthxCTrHLDkn/xVoMejl+qb Me8n3aplq6CQK1d9jjQseR8w1Z4mM8oCUhL24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681945037; x=1684537037; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g22FS7H3jiae+Nq35iKba9yRyiXUFZk5tjGcb2Ngrro=; b=bikN8eQhgErI3YNKPBKgsQovWlJNtLZ2Ayv2tIllZ9o/OudANLYFQ64ihy6fyNNKHV 2orvd5om/NjWedwi8UrUELY2F1QVPLDagfiFUZgTBbay5rWjmU//hNn7JZ/adyEbHwNJ /m02BOxdARJX8hLtuR6Fz/m2NGmZ9+h3jHMZ2mAdA9kO4jF1MDgmDQvGuXlJSWfxMJ5P qfk9fQNC/YmLpde+BhGv9oOTK2+5yGoMtuI2HP8aLOVOkHWEFK63NqkImBi5QYeE7Xpc KST1rpJTdbxpykxopH1XNUj+ODSqwyGZBob1jNIzPrc+emlx+nYRgp+waix0KeodBDWV OKcA== X-Gm-Message-State: AAQBX9cNy4e4+MvsKDAEEcCkfaTO5s+mkP1Y6MvZfp14JI5UxL8nfqML nJxsCu/gEsDvmSFa6m3Y8Mu7+w== X-Received: by 2002:a17:90a:6707:b0:247:6619:61de with SMTP id n7-20020a17090a670700b00247661961demr4179810pjj.46.1681945037310; Wed, 19 Apr 2023 15:57:17 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:8b1:fa03:670e:b784]) by smtp.gmail.com with ESMTPSA id h15-20020a17090aea8f00b00246ea338c96sm1847101pjz.53.2023.04.19.15.57.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 15:57:16 -0700 (PDT) From: Douglas Anderson <dianders@chromium.org> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Sumit Garg <sumit.garg@linaro.org>, Daniel Thompson <daniel.thompson@linaro.org>, Marc Zyngier <maz@kernel.org>, Mark Rutland <mark.rutland@arm.com> Cc: ito-yuichi@fujitsu.com, kgdb-bugreport@lists.sourceforge.net, Chen-Yu Tsai <wens@csie.org>, Masayoshi Mizuma <msys.mizuma@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Ard Biesheuvel <ardb@kernel.org>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, linux-arm-kernel@lists.infradead.org, Stephen Boyd <swboyd@chromium.org>, Lecopzer Chen <lecopzer.chen@mediatek.com>, Thomas Gleixner <tglx@linutronix.de>, linux-perf-users@vger.kernel.org, Douglas Anderson <dianders@chromium.org>, Jason Wessel <jason.wessel@windriver.com>, linux-kernel@vger.kernel.org Subject: [PATCH v8 07/10] kgdb: Expose default CPUs roundup fallback mechanism Date: Wed, 19 Apr 2023 15:56:01 -0700 Message-ID: <20230419155341.v8.7.I21d92f8974c8e4001a5982fea6c98da1bed33ef5@changeid> X-Mailer: git-send-email 2.40.0.634.g4ca3ef3211-goog In-Reply-To: <20230419225604.21204-1-dianders@chromium.org> References: <20230419225604.21204-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763647305383403758?= X-GMAIL-MSGID: =?utf-8?q?1763647305383403758?= |
Series |
arm64: Add framework to turn an IPI as NMI
|
|
Commit Message
Doug Anderson
April 19, 2023, 10:56 p.m. UTC
From: Sumit Garg <sumit.garg@linaro.org> Add a new API kgdb_smp_call_nmi_hook() to expose default CPUs roundup mechanism to a particular archichecture as a runtime fallback if it detects to not support NMI roundup. Currently such an architecture example is arm64 supporting pseudo NMIs feature which is only available on platforms which have support for GICv3 or later version. Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Tested-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> --- (no changes since v1) include/linux/kgdb.h | 12 ++++++++++++ kernel/debug/debug_core.c | 8 +++++++- 2 files changed, 19 insertions(+), 1 deletion(-)
Comments
On Wed, Apr 19, 2023 at 03:56:01PM -0700, Douglas Anderson wrote: > From: Sumit Garg <sumit.garg@linaro.org> > > Add a new API kgdb_smp_call_nmi_hook() to expose default CPUs roundup > mechanism to a particular archichecture as a runtime fallback if it > detects to not support NMI roundup. > > Currently such an architecture example is arm64 supporting pseudo NMIs > feature which is only available on platforms which have support for GICv3 > or later version. > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > Tested-by: Chen-Yu Tsai <wens@csie.org> > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > (no changes since v1) > > include/linux/kgdb.h | 12 ++++++++++++ > kernel/debug/debug_core.c | 8 +++++++- > 2 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > index 258cdde8d356..87713bd390f3 100644 > --- a/include/linux/kgdb.h > +++ b/include/linux/kgdb.h > @@ -199,6 +199,18 @@ kgdb_arch_handle_qxfer_pkt(char *remcom_in_buffer, > > extern void kgdb_call_nmi_hook(void *ignored); > > +/** > + * kgdb_smp_call_nmi_hook - Provide default fallback mechanism to > + * round-up CPUs > + * > + * If you're using the default implementation of kgdb_roundup_cpus() > + * this function will be called. And if an arch detects at runtime to > + * not support NMI based roundup then it can fallback to default > + * mechanism using this API. > + */ > + > +extern void kgdb_smp_call_nmi_hook(void); Concept looks sensible but this is a terrible name for aa command to round up the CPUs using smp_call... functions. Whilst it is true it that kgdb_roundup_cpus() does use kgdb_call_nmi_hook() internally that doesn't mean we should name functions after it. They should be named after what they are do, not how they do it. Something more like kgdb_roundup_cpus_with_smp_call() would be a much better name. Daniel.
Hi, On Fri, May 12, 2023 at 6:49 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Wed, Apr 19, 2023 at 03:56:01PM -0700, Douglas Anderson wrote: > > From: Sumit Garg <sumit.garg@linaro.org> > > > > Add a new API kgdb_smp_call_nmi_hook() to expose default CPUs roundup > > mechanism to a particular archichecture as a runtime fallback if it > > detects to not support NMI roundup. > > > > Currently such an architecture example is arm64 supporting pseudo NMIs > > feature which is only available on platforms which have support for GICv3 > > or later version. > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > Tested-by: Chen-Yu Tsai <wens@csie.org> > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > > > (no changes since v1) > > > > include/linux/kgdb.h | 12 ++++++++++++ > > kernel/debug/debug_core.c | 8 +++++++- > > 2 files changed, 19 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > > index 258cdde8d356..87713bd390f3 100644 > > --- a/include/linux/kgdb.h > > +++ b/include/linux/kgdb.h > > @@ -199,6 +199,18 @@ kgdb_arch_handle_qxfer_pkt(char *remcom_in_buffer, > > > > extern void kgdb_call_nmi_hook(void *ignored); > > > > +/** > > + * kgdb_smp_call_nmi_hook - Provide default fallback mechanism to > > + * round-up CPUs > > + * > > + * If you're using the default implementation of kgdb_roundup_cpus() > > + * this function will be called. And if an arch detects at runtime to > > + * not support NMI based roundup then it can fallback to default > > + * mechanism using this API. > > + */ > > + > > +extern void kgdb_smp_call_nmi_hook(void); > > Concept looks sensible but this is a terrible name for aa command to > round up the CPUs using smp_call... functions. Whilst it is true it that > kgdb_roundup_cpus() does use kgdb_call_nmi_hook() internally that > doesn't mean we should name functions after it. They should be named > after what they are do, not how they do it. > > Something more like kgdb_roundup_cpus_with_smp_call() would be a much > better name. Sounds good. I'm happy to spin with this rename, though I was kinda hoping to drop ${SUBJECT} patch if folks were OK with patch #10 in this series [1]. I personally think that's the right way to go but it's unclear to me if arm64 maintainers will think it's a hack (despite the fact that arm32 implements the "nmi" functions with regular IPIs). For now, maybe I'll think positive thoughts and hope that folks will have the time to review the series soon. If another few weeks go by then I'll send a v9 with just your comments addressed. If nothing else, maybe you can land the kgdb parts in a tree targeting v6.5 and then when arm64 folks have the bandwidth then it will be easier to get them landed. [1] https://lore.kernel.org/r/20230419155341.v8.10.Ic3659997d6243139d0522fc3afcdfd88d7a5f030@changeid -Doug
Hi, On Mon, May 15, 2023 at 4:21 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Fri, May 12, 2023 at 6:49 AM Daniel Thompson > <daniel.thompson@linaro.org> wrote: > > > > On Wed, Apr 19, 2023 at 03:56:01PM -0700, Douglas Anderson wrote: > > > From: Sumit Garg <sumit.garg@linaro.org> > > > > > > Add a new API kgdb_smp_call_nmi_hook() to expose default CPUs roundup > > > mechanism to a particular archichecture as a runtime fallback if it > > > detects to not support NMI roundup. > > > > > > Currently such an architecture example is arm64 supporting pseudo NMIs > > > feature which is only available on platforms which have support for GICv3 > > > or later version. > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > > Tested-by: Chen-Yu Tsai <wens@csie.org> > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > > > > (no changes since v1) > > > > > > include/linux/kgdb.h | 12 ++++++++++++ > > > kernel/debug/debug_core.c | 8 +++++++- > > > 2 files changed, 19 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h > > > index 258cdde8d356..87713bd390f3 100644 > > > --- a/include/linux/kgdb.h > > > +++ b/include/linux/kgdb.h > > > @@ -199,6 +199,18 @@ kgdb_arch_handle_qxfer_pkt(char *remcom_in_buffer, > > > > > > extern void kgdb_call_nmi_hook(void *ignored); > > > > > > +/** > > > + * kgdb_smp_call_nmi_hook - Provide default fallback mechanism to > > > + * round-up CPUs > > > + * > > > + * If you're using the default implementation of kgdb_roundup_cpus() > > > + * this function will be called. And if an arch detects at runtime to > > > + * not support NMI based roundup then it can fallback to default > > > + * mechanism using this API. > > > + */ > > > + > > > +extern void kgdb_smp_call_nmi_hook(void); > > > > Concept looks sensible but this is a terrible name for aa command to > > round up the CPUs using smp_call... functions. Whilst it is true it that > > kgdb_roundup_cpus() does use kgdb_call_nmi_hook() internally that > > doesn't mean we should name functions after it. They should be named > > after what they are do, not how they do it. > > > > Something more like kgdb_roundup_cpus_with_smp_call() would be a much > > better name. > > Sounds good. I'm happy to spin with this rename, though I was kinda > hoping to drop ${SUBJECT} patch if folks were OK with patch #10 in > this series [1]. I personally think that's the right way to go but > it's unclear to me if arm64 maintainers will think it's a hack > (despite the fact that arm32 implements the "nmi" functions with > regular IPIs). > > For now, maybe I'll think positive thoughts and hope that folks will > have the time to review the series soon. If another few weeks go by > then I'll send a v9 with just your comments addressed. If nothing > else, maybe you can land the kgdb parts in a tree targeting v6.5 and > then when arm64 folks have the bandwidth then it will be easier to get > them landed. > > [1] https://lore.kernel.org/r/20230419155341.v8.10.Ic3659997d6243139d0522fc3afcdfd88d7a5f030@changeid Breadcrumbs: I've dropped this patch and several others in v9 [1] by embracing the idea of using a normal IPI as a fallback. [1] https://lore.kernel.org/r/20230601213440.2488667-1-dianders@chromium.org/
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h index 258cdde8d356..87713bd390f3 100644 --- a/include/linux/kgdb.h +++ b/include/linux/kgdb.h @@ -199,6 +199,18 @@ kgdb_arch_handle_qxfer_pkt(char *remcom_in_buffer, extern void kgdb_call_nmi_hook(void *ignored); +/** + * kgdb_smp_call_nmi_hook - Provide default fallback mechanism to + * round-up CPUs + * + * If you're using the default implementation of kgdb_roundup_cpus() + * this function will be called. And if an arch detects at runtime to + * not support NMI based roundup then it can fallback to default + * mechanism using this API. + */ + +extern void kgdb_smp_call_nmi_hook(void); + /** * kgdb_roundup_cpus - Get other CPUs into a holding pattern * diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c index d5e9ccde3ab8..14d40a7d6a4b 100644 --- a/kernel/debug/debug_core.c +++ b/kernel/debug/debug_core.c @@ -238,7 +238,7 @@ NOKPROBE_SYMBOL(kgdb_call_nmi_hook); static DEFINE_PER_CPU(call_single_data_t, kgdb_roundup_csd) = CSD_INIT(kgdb_call_nmi_hook, NULL); -void __weak kgdb_roundup_cpus(void) +void kgdb_smp_call_nmi_hook(void) { call_single_data_t *csd; int this_cpu = raw_smp_processor_id(); @@ -269,6 +269,12 @@ void __weak kgdb_roundup_cpus(void) kgdb_info[cpu].rounding_up = false; } } +NOKPROBE_SYMBOL(kgdb_smp_call_nmi_hook); + +void __weak kgdb_roundup_cpus(void) +{ + kgdb_smp_call_nmi_hook(); +} NOKPROBE_SYMBOL(kgdb_roundup_cpus); #endif