From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9164F13A3F7 for ; Fri, 5 Jun 2026 21:30:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780695005; cv=none; b=OHGq6bgnUEfksPoMCF19UGUYMVH5CfXa459U9BEeZ9eaSbU8dEVDbLZwGEyPHG+jlstVRDfO5/yeLEc9q72O/phDezJ59WSi1+Aocn+x2v1e3KxWcvEB+3roux1sSMzCFCguRpi4JCSnVG9ZF4F0gi4FclV80Zz7nFBsNDgeBCo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780695005; c=relaxed/simple; bh=w2BsQXVg2qYCh4HN60UH/xrj7ydWY+coRaO6kASq0Jw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FiEve6vQ0j33mFxVe0GmBYhOPMv653ML9oSWfwffEj7hZ1DVqtzuVTkHzn5mQ2QKox7ZYFg5+40Gc3UxpXdVkDq7lJ4g5weTW44d20pdqj3fTfZDA82ReqZAu6asVp5Nk5ocve4SWKTWkEZ8o23QN65YDRb/xxdX9OthUWLAnJc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name; spf=pass smtp.mailfrom=shutemov.name; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b=lsV4jnVM; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Er1ZaO7T; arc=none smtp.client-ip=103.168.172.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shutemov.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b="lsV4jnVM"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Er1ZaO7T" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 57255EC01F2; Fri, 5 Jun 2026 17:30:02 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 05 Jun 2026 17:30:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1780695002; x=1780781402; bh=GvUn30TBCS4Zm3lx2W+s/4iNVlrmIOOc dyF2l5T6bVw=; b=lsV4jnVMMml2Z5JVZZSb3QqYvP5fOhplJHutkEpZOC0P6eQw UUUURrnvSh41zAvkFxCHOtpAWjW3DwLne8okVnDcoyHmEiTqNVG6oYX+5/ZjqKrR 4RaOu9nnl5WvNEUp+1wrafWjwT+3HLMQph+EGE8n1ClYbKuUnn2P7wQMVYe4/73a 3CNKV98sD65duhm/xwZUvgXt25Ik6UDWB09MoB05YcoLeEXcEug4otb15eYY9WMs IA5gtP6iJPe2XAxb+gdjN34K9a1MShHJE6Z7OkSR0iUs+cHc+emp899ja5JVxzEa tXZZEPNS1M8d26+Upf0I3j0kL4yWZ/sm6NMGUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1780695002; x= 1780781402; bh=GvUn30TBCS4Zm3lx2W+s/4iNVlrmIOOcdyF2l5T6bVw=; b=E r1ZaO7Tzo+mBX7PCOSNme2T6Vt3IA9DsvVagP2Pnvsa/CJJdR8lXnb4vsx1e0jKu UHZxb1WdT1Cat7phtlQX7d9uRphkr4yIsvqTcB+hAflMcC+xK9PlFzFFS6kpYBvE Cwc2oah9/iI4SbhRoUmCf4FMUv+ULGaNb7Wx7JgWE5VJs+neI3Tdz7CtXTk/LTpS C747dgnNXrAH1ikREfr6U47wHpvz9pzMGoPn2VP1bLZK9kP9IgIbnCA5rqMHOKN2 fJKtnh/CE8jgR9DBZR/H9/oQiJtgp+iRS6Vy/9VvmtkWgsHGdRedlUxxih7d8GIo 9XSojEOt2XknQ007yeqvw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGT3vO/WGTlEyxfWXbodvnZRmgEDm1o9LlJ/+LRF68W8Z2nser0+LniSG+96nKb+H pOylecktyziBagvY49pxEJBjjkpQL8mgWF5v1uGd1s+h6I5zzlQbM7AHlbCH/iTWEAPmW6 PSVh7KQ0UpCrZmv2ekvGKVSTBMc2xq77fqnB36j51Xf/btMi0DPvJiVEVJ113sswsm72zM c1Ob4ECtKaqLnjX8INndbIsjJj8TAReV3dVZrqx+gKmV/udgPeAOLBMtvJtf5Xi9z/fM4q zR3wvjNvuZLT+4A5ZR9Gslu7kzxa47KFBhqSuq1/K8gU/GNvl3Ruhc3zbNG7sLUDfGaJGq S+v+TTf2sRUv+yvDSjBcWsL/beNP5PcN8l6vkgxpLyoIgUkloXaV5tVsHfW5/HjFbM1h9H ++ReRsw/33SuNMrKvyLTaBLJ0Qp1NfUY6nhOKYg6hcvFMElvJ+RIQYH6e1x4wLXqK04P5M QywHw21Le7e0o7Kg15x0VvpUbbbWe6CIzAvq04cBt6emSLOwBrL2o5+itaggLzzHPm65kR zhsqtRFAP1ZPEHvwqTbxdjekEWiuZRNN6v+w/arDgJD9tjnHje7FvwH5if5ceAd36/H91q 3Kz/hAFVuYEEhHohAIbtn6hndoyzzKUd9fSuUTZO1fnswAD5ykflsXC7qQhQ X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 Jun 2026 17:30:00 -0400 (EDT) Date: Fri, 5 Jun 2026 22:29:59 +0100 From: Kiryl Shutsemau To: Doug Anderson Cc: Catalin Marinas , Will Deacon , James Morse , Mark Rutland , Marc Zyngier , Petr Mladek , Thomas Gleixner , Andrew Morton , Baoquan He , Puranjay Mohan , Usama Arif , Breno Leitao , Julien Thierry , Lecopzer Chen , Sumit Garg , kernel-team@meta.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] drivers/firmware: add SDEI cross-CPU NMI service for arm64 Message-ID: References: <145b9e98b12a7d314fc4a203075f65c3a0c3a913.1780496779.git.kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jun 05, 2026 at 01:54:00PM -0700, Doug Anderson wrote: > Hi, > > On Wed, Jun 3, 2026 at 7:36 AM Kiryl Shutsemau wrote: > > > > @@ -928,11 +929,19 @@ static void arm64_backtrace_ipi(cpumask_t *mask) > > void arch_trigger_cpumask_backtrace(const cpumask_t *mask, int exclude_cpu) > > { > > /* > > + * Prefer the SDEI cross-CPU NMI provider when active: firmware > > + * dispatches the event out of EL3 and reaches CPUs that have > > + * interrupts locally masked, without the per-IRQ-mask cost that > > + * pseudo-NMI pays for the same reach. The plain IPI path below > > + * can't reach such a CPU unless pseudo-NMI is enabled. > > + * > > * NOTE: though nmi_trigger_cpumask_backtrace() has "nmi_" in the name, > > * nothing about it truly needs to be implemented using an NMI, it's > > * just that it's _allowed_ to work with NMIs. If ipi_should_be_nmi() > > * returned false our backtrace attempt will just use a regular IPI. > > */ > > + if (sdei_nmi_trigger_cpumask_backtrace(mask, exclude_cpu)) > > + return; > > nmi_trigger_cpumask_backtrace(mask, exclude_cpu, arm64_backtrace_ipi); > > nit: instead of one comment block, I would have broken it up in two. Like: > > /* > * Prefer the SDEI ... > */ > if (sdei_nmi_trigger_cpumask_backtrace(mask, exclude_cpu)) > return; > > /* > * NOTE: though ... > */ > nmi_trigger_cpumask_backtrace(...); Makes sense. > > } > > > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > > index bbd2155d8483..6501087ff90d 100644 > > --- a/drivers/firmware/Kconfig > > +++ b/drivers/firmware/Kconfig > > @@ -36,6 +36,25 @@ config ARM_SDE_INTERFACE > > standard for registering callbacks from the platform firmware > > into the OS. This is typically used to implement RAS notifications. > > > > +config ARM_SDEI_NMI > > + bool "SDEI-based cross-CPU NMI service (arm64)" > > + depends on ARM64 && ARM_SDE_INTERFACE > > + help > > + Provides SDEI-based cross-CPU NMI delivery for hooks that need > > + to reach interrupt-masked CPUs on silicon that lacks FEAT_NMI: > > + > > + - arch_trigger_cpumask_backtrace() (sysrq-l, RCU stalls, > > + hardlockup_all_cpu_backtrace, soft-lockup secondary dumps, > > + hung-task auxiliary dumps) > > + > > + The driver registers a handler for the SDEI software-signalled > > + event (event 0) and reaches a target CPU by signalling it with > > + SDEI_EVENT_SIGNAL. Firmware delivers the event out of EL3 > > + regardless of the target's PSTATE.DAIF -- forced delivery into a > > + CPU wedged with interrupts locally masked. > > + > > + If unsure, say N. > > Is there some downside to this? It seems like anyone who has the SDE > interface would want this. Not sure why you'd suggest people say "N". No real downside -- without the software-signalled event the driver stays inert, and there is no cost until an event actually fires. The "say N" is caution, not a technical limit: so far this has run on QEMU (TF-A) and one hardware platform, and the interesting paths depend on each vendor's SDEI implementation at EL3. I'm not sure vendors would care to run SDEI_EVENT_SIGNAL validation. Maybe we want to see more data points first? But maybe I am too cautious. Happy to flip the recommendation (or add default y) in v2 if that the consensus. > Other than the nit, this looks reasoanble to me, though I'm a complete > noob when it comes to SDEI... > > Reviewed-by: Douglas Anderson Thanks! -- Kiryl Shutsemau / Kirill A. Shutemov