From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com [103.168.172.148]) (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 D44DA3F6C59 for ; Mon, 29 Jun 2026 16:53:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.148 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782752039; cv=none; b=Ihlg5KiOTWnL0P/i566YyJa01//FET7nhUYE/Tt5eBIX1U3pzFpSQ8fyNaW9TVkwb2/QPBq5aLEkd6yABb+2e8q6RKgyxcbm3qbtSs8Q7IdnkGaHfhMirv3LVqrVo3axVmsQugQD52GvM/CPljOScjkaES3DCoAuKxjev9p+Fj4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782752039; c=relaxed/simple; bh=t2jNWfDZaRDLf9LTWPSgfk/4uUGFHkL3XTGq6qM+MJw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Sls79h55nv9nCfe8ldF3O6+CX0b6zWwemvU9sHvCtIlGKB8PC3giWUc4s+hpot29WXWvkdl1MrAxOOgLgRTq3D0rMbtneenOxVZc+TWraDRJCxruWs5k6LIcm5Za4s6prejS7JvIYOQQXuSyMwvhXpSzwojmNbRGyw0QKGQHEoU= 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=NZGXNR6l; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=VcLy23F2; arc=none smtp.client-ip=103.168.172.148 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="NZGXNR6l"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="VcLy23F2" Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 2B039EC006E; Mon, 29 Jun 2026 12:53:57 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Mon, 29 Jun 2026 12:53: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=1782752037; x= 1782838437; bh=6d/g78nARanRf8gSDZnSYai0WcH3apHlQ9zVtHuPszY=; b=N ZGXNR6l5Q5v6NSr0q7LeE3fgkfIyMitsQCjVn7v8EvVru91478oo7MeDOSbQM26m jXS7ZK8I0eDYmVea6vlN5n1uZ/0jhMJZWxwctEzmWRFX9JwQ+g5dYAiwmnABUeqO iQQnaeVwxmFbXfcW303hDGplMiP925vknxX7jjhBw/aB6ZIPOdeLrKpiigBS+NH7 QKi59d5tw57ViTA7i/7lozw/kxWgNHfc5ViGHZqaL+KIxTxAptlsY2roq/A8WR+K 6RG0YPVeTHFlz+8apZFIB33tG9nAbyhib9xNDIePDD2ahIbtLVBqA+GjPd18FGRY 4coNxb4WD7seVtSuvUYEw== 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= 1782752037; x=1782838437; bh=6d/g78nARanRf8gSDZnSYai0WcH3apHlQ9z VtHuPszY=; b=VcLy23F2+rXWsexJnDQ9eY3tf1dz+WSD4OsddeGafhV3XOXsvza vPyvN+x/K6o9oIUQGmrnDOW+Y3eMWGF/O2/ieYNRNtL30o5MLRZ22/9G4paMnV7k IUcNB2wf5gs7QpkFkR54877YrjuOdaooBd2M1Z/HVL8+bTCmi7pVKYCSJRMqU1Wz 9My4n07gFiuajN34yG0+jXFr9vACJlGYx6cM1Uj07adSwT8JQvRZ3BLb8vsTTSQx fU6iyNJQyL0xTJzPAdJQ5IlYNrlL/R8k6aHNH2iFr/hXcUgmu6ELLqlVnH0Nadxw uhhpKQgzIpoSPvrC7tk41ruayEwpqjuJdGA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEzzn6OgJCgoJErvGmXtkQgHIU8zND7m0wTMLGAHBlOG8NESTBmLsw97avQ8mqKmv 6Utolx1pAcqyJypNeKEtYm8JWl1pX9x1mCAwaKZrBoFF445lJbgx9KdFGtEPq+K29okb2/ GX2qOqaHUaxHPYGzgJ1ezEOlhOax32ciKt1bvZjbGyUAdl9/pp7SKN4tg2364f/kIciFBx vhKBZzOA8AfVHiY8IYqGu/eTt2W4ocxoQcBSy9kono6UHQpJoHumvxlql/oZaZ2i6ChXzx r7Q9YXOJnEIcwzDi6PHmtDTyBWgHTXI/qLdwYfMvCburY83E7VBnbeXga/IYsJsPFZk/Y9 tum8cSWFzNNeUvGxZrk1hq+viFDxGo+aNzQgla9mg7a/+P2RZ8KJETcTb/0oTKTrIvFqL8 G0tr9UfyC6EsqIwIIzYROWTUZca8Fsn0KRCX0yM0ewQdjBZxEUdczSxTYT0MOilPHSaiZP zDAf/DV+WFpKAAq3/igyF3nd7b04DgMv35CwlN8+D0rJPnANvcHDbCH5K5oP4BLZVS24R3 wr6mAhbrpE+EO6a9mwyDr9uHGPBvjlDC+LsgbGwjtS6pZ11e7SduTP8dGHBXMINONAbuhV fn0TODSdVkaKHjbJdYQVJSgrfx4zbXgXdv6o5gmfGO0U1UzoCBhnd8Nwg3Vg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 29 Jun 2026 12:53:56 -0400 (EDT) Date: Mon, 29 Jun 2026 17:53:55 +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 Mon, Jun 29, 2026 at 04:54:18PM +0100, Catalin Marinas wrote: > Have you tried SDEI_EVENT_COMPLETE_AND_RESUME instead? Just COMPLETE > won't return to the kernel. We have sdei_handler_abort() to complete the > event and, hopefully, you can continue with the CPU_OFF. It's a work > around the TF-A non-compliance but I think this is useful even if you > don't issue the CPU_OFF (e.g. no CPU hotplug, just the park loop). Tried it. The result is the opposite of what I expected, and it argues against doing the complete at all under QEMU's TF-A. Same A/B harness as before -- a CPU wedged with interrupts masked is stopped via the SDEI rung; I only vary how its handler ends. kdump capture kernel boot under QEMU: - park, event left uncompleted (current series): boots to a shell - sdei_handler_abort() then CPU_OFF: hangs at SDEI re-init - sdei_handler_abort() then park (no CPU_OFF): hangs at SDEI re-init - CPU_OFF, event left uncompleted: hangs at SDEI re-init The third line is the surprising one: completing the event via sdei_handler_abort() and then just parking -- no CPU_OFF at all -- breaks the capture kernel too, at the same point as CPU_OFF does. The only variant that boots is the one that leaves the event uncompleted and parks. So here it's completing the event that the capture kernel trips over, not the dangling dispatch -- backwards from the non-compliance theory, where completing should be the safe thing and "useful even without CPU_OFF". -- Kiryl Shutsemau / Kirill A. Shutemov