From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b2-smtp.messagingengine.com (fhigh-b2-smtp.messagingengine.com [202.12.124.153]) (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 1E9C23EFFC1 for ; Tue, 9 Jun 2026 10:21:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.153 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781000516; cv=none; b=R5xblOXAUbNfiOE2RVuP77O0vVaSbI3ur1rK6jrkaC6Z2pLWJH3KS0fbkwjm4xHN7ENwjiP3h56VIPAcL8Mk5FIwAxPSkSeDj79fIxmg+tqNL0qLBuXFjNCqJCFyxUvptALO05M61uVsyoRwQeN/W5PofQJ3ootNv9qollMWorA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781000516; c=relaxed/simple; bh=xc2D/47C9R5y/11ZReun8yUQMWhSkfS6jD8VqfjvDBY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Px1xYHNgm+ATyrAdkHIHgjC9etaypwoXOSeHRt1M+VSO5y898T8mJ3imTLV8GY8o1YWLT8H4tFy6XgRQZ4pZzUCrpGO80tip+E+xztfNd2rwuI+aupHonF8OXuC2vrxV/nqCE6uKM4aU05wbNXR4UI6PNuGZTid4S7vAZoCZ5P8= 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=LMvTZafk; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=F8dTsqwH; arc=none smtp.client-ip=202.12.124.153 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="LMvTZafk"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="F8dTsqwH" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id F3E597A01DD; Tue, 9 Jun 2026 06:21:52 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Tue, 09 Jun 2026 06:21:54 -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=fm2; t=1781000512; x= 1781086912; bh=ilTpfhF1TQEFmYf28SNwirdITOkRxUVFe4Pi+3nX/fk=; b=L MvTZafklm6pirpgWULiMME4ofFgQnQyajJTBZ/JTk2kQdWbQ7usp5s93IejBMqHn gd9lCLtjZonw4mI2GB+MFjmungjhswb+HHUzmVYkGjitZBTPzlQNIY+8GZwIVlF2 prYPOffuPcSqqufwgqdyA+OhTBy6RQueekuBbpa7oneutoxIuXL9R8UOst9xhfDd 6GCICWklYZeC7qsHUviSlY1P+YfldkhyzoxFiFDj7gFJ6PtGYwnShA7NoX0uf0g1 Yv6InD+tfK8Jgp14xM5IIq/h6Ag9MW6jdi3x+DxcNUYxPvq/AJpRWDwr73V5mupP rqvd8iMrP43BqRYL9lOIg== 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= 1781000512; x=1781086912; bh=ilTpfhF1TQEFmYf28SNwirdITOkRxUVFe4P i+3nX/fk=; b=F8dTsqwHKD1mtzn1fmk1xRl23AFGtIRXKARdiNRm3nn6B+jk7cs PKNhxYSZRpAWCgzDi5TiMrxiSw5/uKKlSoB+SqN8T7SEA0CRnDwIUEVxFVpx/Zyc uJ+sFRl1bSWDZKpzoy4LY0Z7juNVIwQqhvMYZBYJf+SLm2KPympCYI7WNbw0+a6+ tUtIHgjgyE0DjmlamAEaEXz1PxAh2Yzn1KMXuAKO1BLpa5qDeXsJjG0EHtsFwxlT eR8QoCiH0ZAGkdAL88bZwWK88XaAiDrfuGn1FBtDuJpTTaTD6ycZ5bNT8Eqma0YL xR8Huid/9DMaeTjV3Pm6tSsbp6nC8W4qXEw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEw8PCireUhD2Te30Mqdwt+PvgCXGBAsv4g7AkCagsJvs/QPTVeTaGl5+FbMgDmWj e2FLorIG0RlcycKDz0QZrQolMDi+MlHxcXJ/OLkDuQ5Mr6PMgKF5Zqm0y1R2oI5nMEP27Z uoeYbA8E8RzrfluscWrFSgOtHEKaWCebeXcY7RSKuFu0cBuLAuP0yuHOG/L4rCXpUrWmuj loojJ7MaoVuUQwSoZ0qRuQdxaF7jXkb+n3TcnSh3pJj2ZBalUN672m7lkPlTIvzXdLqgaC //uoXljtwk76/m/TeaXrpPvmxQs/iAR0fTazfsbwet2RzDmA2siPiOaOCHHVj4xPDvtvih nWqIMAErxw78eoPCcffU5cD1YNFRFy5U6op7QQPBrLBvIxGAhOOIgGuOrs4E5a8mc8zugO E2WsPC3UQXpYmASxXMBFtLvpA0iuPg6cywqWbgubX53a/rAvG71/oGeltWq2sGfiuTX1s+ vtE7o2tY5cSpooqkwPFD9v5hxYzuog+tFj06AbAGutt27kp2zqkIJ+dhRK+9OHAKENr9Va 3z0URZ2WilEYExUgDT2sxgh1FRPdzfzpHJiywfd4yL6NYH41/Sd54xY3BCK4ptX3vSUBzg VZDUDMJ16s5Ko+bMLq0B07li9+gAsc53ysNCQCMRieayJwIBBAJ56SX5KZxg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jun 2026 06:21:51 -0400 (EDT) Date: Tue, 9 Jun 2026 11:21:49 +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 4/4] arm64: route crash_smp_send_stop() last resort through SDEI Message-ID: References: <54cb99db3c981dc39eb3031aff5caeaadb09e8b9.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=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jun 05, 2026 at 10:46:11PM +0100, Kiryl Shutsemau wrote: > On Fri, Jun 05, 2026 at 01:42:57PM -0700, Doug Anderson wrote: > > > + sdei_nmi_crash_smp_send_stop(); > > > > It feels weird to me that you're adding SDEI for "crash stop" but not > > for regular "stop". It feels like you should modify smp_send_stop() to > > fall back to SDEI if sending the NMI failed, instead of adding this > > separate path. > > Fair. A wedged CPU ignores the reboot-path stop just the same, and the > escalation logic already lives in smp.c, so I'll restructure in v2. > > One thing to sort out there: this patch parks the stopped CPU inside > its SDEI handler without completing the event, which is fine for the > crash case (nothing expects the CPU back before reset), but a generic > stop path probably wants SDEI_EVENT_COMPLETE_AND_RESUME into a parking > stub instead, so that e.g. a regular kexec can bring all CPUs back up > in the new kernel. I'll look into that as part of the rework. Regular kexec takes different path and offlines CPU normally. So the next kernel can start them. But crash kernel cannot re-use wedged CPU. C&R alone doesn't buy us anything. We need to get the CPU to CPU_OFF. I am trying to do this, but so far no luck. Crash kernel fails to start at all if try to do C&R and then CPU_OFF. C&R alone works, but CPU is still unreachable by the next kernel, as expected. -- Kiryl Shutsemau / Kirill A. Shutemov