From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a7-smtp.messagingengine.com (fhigh-a7-smtp.messagingengine.com [103.168.172.158]) (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 26AD03BBFBC for ; Fri, 26 Jun 2026 19:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782502860; cv=none; b=qoysdhsKBipeUpDsu5ji3/gd8R//A9rursxKqm4fx+vcgDh73HzvPKUlF3UjNeD+QUSjdK0lBYU9eTAoWDJwhtXm2cc6kxgDpuq31K7UwPv/WF/keukuvyuPIl74bip/eVmWNWbBfY1F5cv1n617MszDfXVcCUfRg65KxRgKWi8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782502860; c=relaxed/simple; bh=nPR/WPOdP93gkpZNiRwdR1og9O9jfABi7l226CFsauo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fMl9PBV/iFQVCPNcEt53zdpmvmJmHLHWFeqiV+R/smG3mdeIR0KzrbCpcBdspUjnq5G3YJXrtln0mxZuvH6WVdfJY8hAVHkkCtg7TNlPd45Lg7i+xOQwFcHAF1EZSJadEjFCCU8XIJrPdn7fprZcHzcJVeag0Xb484uJOHXG2EE= 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=Nc35uCDF; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=BhMJ7aih; arc=none smtp.client-ip=103.168.172.158 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="Nc35uCDF"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="BhMJ7aih" Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 2F804140011E; Fri, 26 Jun 2026 15:40:57 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Fri, 26 Jun 2026 15:40:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc: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=fm3; t=1782502857; x= 1782589257; bh=xZleOJPXENCZTiyBq0Gs6OTAspcEjOZFDjSgU59flgU=; b=N c35uCDFov6urT3p2RzZ7fApzEqHgpOvrspC10elAhfsmS5G/MuInMb2HPPu9cbeP VmfEtwAmilyIHmbdMPlMLHkJ1RySgQYKBILdM+P45VYD/gGLcltuch+311/1ETUr K0W36N09WhQTJs49/Bs/18P2Wonjy6o+9qh13a8UCjW04NYGaNlb3DAZyn5YF3CU CouymF5fI9iWPlpXV0c8LYGQDaCEQk4elruC9fyf5NQX7t/fhKYKu1FiMumFVAsk vBWD0l/P3Oav7TrOzYMOlHtjP41ewai0w2pqnB4QjUq5wZ3YJcffBv+i+Rr7ALqO KyVLYP0Mq1zhOG9xI7JRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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= 1782502857; x=1782589257; bh=xZleOJPXENCZTiyBq0Gs6OTAspcEjOZFDjS gU59flgU=; b=BhMJ7aih3j1kXphoSb75WW/5H6a4SDRqBgygAM4eynysyEgghWf 81pZfIjFpAYAxP/39YmzPoG1haC7kwogNvlxsX6bmITcK128ivLd5mVn3enCj4FV OgQDV5afuGpCazkX4LQXO2eWW6hVXydUhfkPMq89smj4uIY09qU9DXM399zPMXL8 1amxDdhRtYdA6Jc0s945T222FIPUOVbYkgAB1/vJHPWd3DXPZ5gFtD9DrN8FkvTQ wYszW274a01gNViA9GorWzmH4UFOo3SNWmYOzM4d2HEqap0kgcCH6ilI1JIb3rvn VvAww7v2bxKz67LzAVPCsT6fo074SySQekQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGW1HqdjaJoFQUXHWjWh9D9hOSFIJsyccNvsLPRtGB9mH7fc1kAT7fHoGH3Hu85I9 k/c3Z7Nb4r54bT5MEEkjmFGiJiu04ZC7NwEzcdsuQvf1CLqjpKYxBI27a6yWDq1/28x1RM 8zsFgUAo5jkHgCzsB5V2Q5N6XYX2veo3WfywnhV2OHrN8xLBECodxM09aiaO1zN7R+k780 Q9KUglIq75DgRugyZRP8YDl3KFlnOp8Qm3bbUE7ljJZEWPz9zlzS+4hWSMxULkCZ3gTwi8 v2K1itOsX+A0jEIbKYds7EgZcectBAfujot9nNFh5LF86Pgk0OqsAih1iMEiHC0XosUek6 FikrX9i3SEXmWGteumPlq9VIPvqQBefAve4qrFZNYi4HN4wHMrWgwwJeLbKX/gJoRSyehR N/Iugv5JP8nbxYKqmAJQAvZ4iT/j2HrdEVRP1fCNvAvtzi/RMAO1tQnTi4nhmq9g/Y2iZI txldL+oBIgDghSB13xufo5A4XXk3HDfUjFKqSvoQLyNih8F8f7WaLzevjwzUE0TOQxLkRU 7dscJsqOjjAVXq6SaKqDVEf4wQumsUe3DUhfIgkuraxmEzSKge6K2L3mGVI9nGZvy+8ET3 E/uHBaXi2Dkz1gFiIFdNzqQFbuVDkPL/BjUZBgreuZdp3fqZdQ+npzruknJg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 26 Jun 2026 15:40:55 -0400 (EDT) Date: Fri, 26 Jun 2026 20:40:54 +0100 From: Kiryl Shutsemau To: Catalin Marinas Cc: Will Deacon , 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 v4 0/4] arm64: cross-CPU NMI via SDEI Message-ID: References: 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=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jun 26, 2026 at 06:07:10PM +0100, Catalin Marinas wrote: > On Wed, Jun 17, 2026 at 08:20:01PM +0100, Kiryl Shutsemau wrote: > > - A CPU stopped by the SDEI rung is parked, not powered off via PSCI > > CPU_OFF. Reaching and dumping the wedged CPU -- the point of the > > series -- works, and it matches the shared stop path's own park > > fallback when CPU_OFF is unavailable. The consequence is that an SMP > > crash-capture kernel cannot re-online such a CPU (it stays "already > > on"); the capture kernel boots and runs on the remaining CPUs. > > Powering the stopped CPU off so a capture kernel can reclaim it > > requires completing the SDEI event and then CPU_OFF, which hit a > > firmware-specific issue still under investigation; it is left as a > > follow-up and does not affect the dump's contents. > > Just to understand, your firmware cannot cope with a PSCI CPU_OFF from > the SDEI handler? This is one of the required calls to be supported. I did chase it a fair bit. Bisecting on Grace: completing the event and parking (no CPU_OFF) works, and so does the stack-switch + C-call setup on its own. The hang only appears once I call PSCI CPU_OFF after the event -- and it persists even with DAIF masked and the GIC PMR reset first, so it isn't leftover interrupt/priority state from the dispatch. It's a silent wedge: no TF-A exception report, nothing after the last console line. But I have not tried calling CPU_OFF directly, without completing the event. I assumed it is required. Will give it a try when I have time. Either way this is a side quest: it only lets a crash kernel reclaim the stopped CPU. The dump itself is complete, so it's nice-to-have, not required for the series. -- Kiryl Shutsemau / Kirill A. Shutemov