From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A1899C531FA for ; Sun, 26 Jul 2026 13:56:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oAqk85PfaZIsBzhpoLVWf76ojRfZbMog0/3PXdHaiAw=; b=4i5Nm8NuZ6ewIElzefDgvAL3Kj zOXWyrPdAQXVHpyPCdYkPs52MFMXNyvoCtWVclGEKKmAabGGrRqAF4loepMUHZX3Brqc81OV6Y6hs hAQXwaJfegPSNNgoByqeGnknwZl/MAUAbBl7i4cf5ueLutB8RYOHRJOYgCpRyoEGqpiw3OFFfa1cD seNgcyqZeQMfRoRVFQ+q16hKptbIealxSra//nLq/PUtyrmZEHOw4z/74H2uNh1Wedy08bMv5w2ea WK/35cN4JkAjjcK97k5/R8dxjqzzaKLyg7SBcR14VlCOGgDYz8jTkf9CJBSW/toF7C79cGsD+LUr3 hlkPhZqQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wnzKg-00000001DYW-36ZO; Sun, 26 Jul 2026 13:55:58 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wnzKe-00000001DYG-3fmx; Sun, 26 Jul 2026 13:55:56 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 131C0400C7; Sun, 26 Jul 2026 13:55:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BA6F1F000E9; Sun, 26 Jul 2026 13:55:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785074155; bh=oAqk85PfaZIsBzhpoLVWf76ojRfZbMog0/3PXdHaiAw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GaFtuCkngOK2YnYTN5/q1DxREdA9n0YxnFFD94dlpKPeV3syaV9BEWdXFYPnF4n5N zGLMhdZFa28zts7sn8Bzmk0pHrqOb/+bDN7q7f3wObebhZqopz9XqGS+9/MEKSeYNl niKRlm85gzOm0xGyRX9mG0FPZNK7UCeJwnVbFHkjokRX0yoJUn+8XGhNsCpW4eot6I tnWFVx6uLM9kwbSLf0AtmgMP58VWEbC1iTdyyj0s2PQyOggZYk4JS0lXXVdmP/dP4G tG2DtyTYxzy+vTTkuT+JuPligFgrrZC4fa4jHGI18KE1STuiFl/8zs32AvWKvilG3k wBDslo24px5YA== Date: Sun, 26 Jul 2026 14:55:49 +0100 From: Will Deacon To: Kiryl Shutsemau Cc: Catalin Marinas , James Morse , Mark Rutland , Marc Zyngier , Doug Anderson , 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 v5 0/4] arm64: cross-CPU NMI via SDEI Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 09, 2026 at 05:16:37PM +0100, Kiryl Shutsemau wrote: > On Mon, Jun 29, 2026 at 04:07:14PM +0100, Kiryl Shutsemau wrote: > > From: "Kiryl Shutsemau (Meta)" > > > > A class of debug/observability features needs to interrupt a CPU that has > > its interrupts locally masked: the all-CPU backtrace behind sysrq-l / > > RCU-stall / hung-task / hard-lockup dumps, and crash_smp_send_stop() > > capturing a stuck CPU's state into the vmcore. On arm64 these need a > > mechanism that reaches a CPU spinning with DAIF masked, which a normal IPI > > cannot. > > Gentle ping. Any feedback? > > I'm looking forward to finding an upstreamable solution to the problem. This is all pretty small, self-contained and it's useful to you, so I'm inclined to merge it. However, the one vague concern I have is about the direction of SDEI in the future. AFAIK, the TF-A implementation is known to have issues, it's not supported at all by R-FA and I worry that the spec is going to fall behind the architecture, particularly as FEAT_NMI becomes available. So it would be good to understand what we're signing up to maintain here. Kiryl, do you see an (eventual) migration over to FEAT_NMI, giving us a path to deprecating SDEI altogether, or do you think the two will live alongside each other for the forseeable future? Cheers, Will